Redis

　　keepalived官方有中文文檔：LVS + Keepalived Chinese application doc - March 16, 2010。　　keepalived 實現VRRP協議，從路由層級實現VIP切換，可以完全避免類似heartbeat 腦裂問題。可以很nice的實現主從、主備、互備方案，尤其是無狀態業務，有狀態業務就需要額外花些功夫了。     既然mysql

根據一些測試整理出來的一份方案：1. Redis 效能對於redis 的一些簡單測試，僅供參考： 測試環境：Redhat6.2 , Xeon E5520(4核)*2/8G，1000M網卡 Redis 版本：2.6.9  用戶端機器使用redis-benchmark 簡單GET、SET操作： 1. 1單一實例測試1. Value大小：10Byte~1390Byte 處理速度： 7.5 w/s，速度受單線程處理能力限制 2. Value 大小：1400 左右 處理速度突降到5w/s

[預告] [3月8日] 《Redis 設計與實現》[預告] [3月8日] 《Redis 設計與實現》2013-02-28 10:36:27自從開始在部落格斷斷續續地寫一些 Redis 的源碼分析文章以來，我一直有這樣一個打算：不是間隔地、分多次地寫多篇 Redis 的源碼分析文章，而是抽出一段時間，對 Redis 的源碼做一次完整的分析，並將其中的關鍵點、以及有趣的部分記錄下來，集結成一個文檔（或者更通俗地說，一本書？）。我在 2012 年 12 月開始將“Redis

 一、簡介：     在過去的幾年中，NoSQL資料庫一度成為高並發、海量資料存放區解決方案的代名詞，與之相應的產品也呈現出雨後春筍般的生機。然而在眾多產品中能夠脫穎而出的卻屈指可數，如Redis、MongoDB、BerkeleyDB和CouchDB等。由於每種產品所擁有的特徵不同，因此它們的應用情境也存在著一定的差異，下面僅給出簡單的說明：      1).

一、簡介：    和大多NoSQL資料庫一樣，Redis同樣遵循了Key/Value資料存放區模型。在有些情況下，Redis會將Keys/Values儲存在記憶體中以提高資料查詢和資料修改的效率，然而這樣的做法並非總是很好的選擇。鑒於此，我們可以將之進一步最佳化，即盡量在記憶體中只保留Keys的資料，這樣可以保證資料檢索的效率，而Values資料在很少使用的時候則可以被換出到磁碟。  

　　準備環境：　　因為找不到可用的1000M網路機器，使用一根直通線將兩台筆記本連起來組成1000M Ethernet網。沒錯，是直通線現在網卡都能自適應交叉線、直通線，速度不受影響，用了一段時間機器也沒出問題。　　服務端：T420 i5-2520M（2.5G）/8G ubuntu 11.10　　用戶端：Acer i5-2430M（2.4G）/4G mint 11　　redis版本：2.6.9　　測試指令碼：./redis-benchmark -h xx -p xx -t set -q -r 1

  使用zookeeper 實現一致性hash。 redis服務啟動時，將自己的路由資訊通過臨時節點方式寫入zk，用戶端通過zk client讀取可用的路由資訊。   服務端使用python 指令碼寫的守護進程：https://github.com/LittlePeng/redis-manager 指令碼部署在redis-server本機，定時ping redis-server 節點失效的情況： 1.伺服器與ZK伺服器失去串連 Session Expired

一、概述：      字串類型是Redis中最為基礎的資料存放區類型，它在Redis中是二進位安全的，這便意味著該類型可以接受任何格式的資料，如JPEG映像資料或Json對象描述資訊等。在Redis中字串類型的Value最多可以容納的資料長度是512M。二、相關命令列表：命令原型時間複雜度命令描述傳回值APPEND key

一、概述：    Redis在設計之初就被定義為長時間不間斷啟動並執行服務進程，因此大多數系統配置參數都可以在不重新啟動進程的情況下立即生效。即便是將當前的持久化模式從AOF切換到RDB也無需重啟。    在Redis中，提供了一組和伺服器管理相關的命令，其中就包含和參數設定有關的CONFIG SET/GET command。二、相關命令列表：命令原型時間複雜度命令描述傳回值CONFIG GET

一、Redis提供了哪些持久化機制：    1). RDB持久化：    該機制是指在指定的時間間隔內將記憶體中的資料集快照寫入磁碟。        2). AOF持久化:    該機制將以日誌的形式記錄伺服器所處理的每一個寫操作，在Redis伺服器啟動之初會讀取該檔案來重新構建資料庫，以保證啟動後資料庫中的資料是完整的。    3). 無持久化：    我們可以通過配置的方式禁用Redis伺服器的持久化功能，這樣我們就可以將Redis視為一個功能加強版的memcached了。    4).

一、概述：      我們可以將Redis中的Hashes類型看成具有String Key和String Value的map容器。所以該類型非常適合於儲存值對象的資訊。如Username、Password和Age等。如果Hash中包含很少的欄位，那麼該類型的資料也將僅佔用很少的磁碟空間。每一個Hash可以儲存4294967295個索引值對。二、相關命令列表：命令原型時間複雜度命令描述傳回值HSET key field

一、特殊編碼：    自從Redis 2.2之後，很多資料類型都可以通過特殊編碼的方式來進行儲存空間的最佳化。其中，Hash、List和由Integer組成的Sets都可以通過該方式來最佳化儲存結構，以便佔用更少的空間，在有些情況下，可以省去9/10的空間。   

一、概述：      和眾多其它資料庫一樣，Redis作為NoSQL資料庫也同樣提供了事務機制。在Redis中，MULTI/EXEC/DISCARD/WATCH這四個命令是我們實現事務的基石。相信對有關係型資料庫開發經驗的開發人員而言這一概念並不陌生，即便如此，我們還是會簡要的列出Redis中事務的實現特徵：      1). 在事務中的所有命令都將會被序列化的順序執行，事務執行期間，Redis不會再為其它用戶端的請求提供任何服務，從而保證了事物中的所有命令被原子的執行。      2).

一、概述：      在Redis中，我們可以將Set類型看作為沒有排序的字元集合，和List類型一樣，我們也可以在該類型的資料值上執行添加、刪除或判斷某一元素是否存在等操作。需要說明的是，這些操作的時間複雜度為O(1)，即常量時間內完成次操作。Set可包含的最大元素數量是4294967295。      和List類型不同的是，Set集合中不允許出現重複的元素，這一點和C++標準庫中的set容器是完全相同的。換句話說，如果多次添加相同元素，Set中將僅保留該元素的一份拷貝。和List類型相比，

一、Redis的Replication：    這裡首先需要說明的是，在Redis中配置Master-Slave模式真是太簡單了。相信在閱讀完這篇Blog之後你也可以輕鬆做到。這裡我們還是先列出一些理論性的知識，後面給出實際操作的案例。    下面的列表清楚的解釋了Redis Replication的特點和優勢。    1). 同一個Master可以同步多個Slaves。    2).

一、概述：      在Redis中，List類型是按照插入順序排序的字串鏈表。和資料結構中的普通鏈表一樣，我們可以在其頭部(left)和尾部(right)添加新的元素。在插入時，如果該鍵並不存在，Redis將為該鍵建立一個新的鏈表。與此相反，如果鏈表中所有的元素均被移除，那麼該鍵也將會被從資料庫中刪除。List中可以包含的最大元素數量是4294967295。      從元素插入和刪除的效率視角來看，如果我們是在鏈表的兩頭插入或刪除元素，這將會是非常高效的操作，即使鏈表中已經儲存了百萬條記錄，

一、概述：    Sorted-Sets和Sets類型極為相似，它們都是字串的集合，都不允許重複的成員出現在一個Set中。它們之間的主要差別是Sorted-Sets中的每一個成員都會有一個分數(score)與之關聯，Redis正是通過分數來為集合中的成員進行從小到大的排序。然而需要額外指出的是，儘管Sorted-Sets中的成員必須是唯一的，但是分數(score)卻是可以重複的。  

一、請求應答協議和RTT：    Redis是一種典型的基於C/S模型的TCP伺服器。在用戶端與伺服器的通訊過程中，通常都是用戶端率先發起請求，伺服器在接收到請求後執行相應的任務，最後再將擷取的資料或處理結果以應答的方式發送給用戶端。在此過程中，用戶端都會以阻塞的方式等待伺服器返回的結果。見如下命令序列：    Client: INCR X    Server: 1    Client: INCR X    Server: 2    Client: INCR X    Server: 3   

一、概述：      在該系列的前幾篇部落格中，主要講述的是與Redis資料類型相關的命令，如String、List、Set、Hashes和Sorted-Set。這些命令都具有一個共同點，即所有的操作都是針對與Key關聯的Value的。而該篇部落格將主要講述與Key相關的Redis命令。學習這些命令對於學習Redis是非常重要的基礎，也是能夠充分挖掘Redis潛力的利器。     

引言在我們遊覽網頁時，隨處可見標籤的身影：進入個人微博首頁，可以看到自己/他人的標籤，微博系統會推送與你有相同標籤的人遊覽博文，大多數博文有標籤標記，以說明文章主旨，方便搜尋和查閱網上購物，我們經常使用標籤進行商品搜尋，如點選 “冬裝” +  “男士” + “外套”