目錄
單節點redis例項的缺陷:
redis集群的目的:
本質:分片原理:
codis之間的槽位同步:
codis的擴容:
codis的犧牲:
codis四個部分及作用:
(1)codis proxy
(2)codis dashboard(codis config)
(3)codis redis(codis server)
(4)zookeeper/etcd
(1)儲存資料量大和高併發的情況下記憶體容易暴漲
(2)乙個redis記憶體受限，受限記憶體過大，資料同步全量同步時間過長，會增加同步失敗的風險，另乙個是redis都是部署在雲伺服器上的，這個也會受到cpu的使用率影響
將多redis例項cpu計算能力匯聚到一起，完成大資料和高併發量的讀寫
codis是乙個**中介軟體，用的是go語言開發的，起乙個中間**的作用，能夠吧所有的redis例項當成乙個來使用，在客戶端操作sdk的時候和操作redis的時候是一樣的，沒有差別。（無狀態）
**中介軟體，通過記憶體儲存著槽位和例項節點之間的對映關係，槽位間的資訊同步交給zookeeper管理
不支援事務和官方的某些命令，原因是分布多個的redis例項沒有回滾機制和wal，所以是不支援的。
將所有key分成1024個槽，對應的就是redis的集群，codis在記憶體中維護槽與redis的關係，槽的數目可以被配置，現將key進行crc32後得到乙個32位的數字，然後再hash%1024後得到乙個餘數，這個值就是這個key對應的槽，這槽後面就是redis的例項。
乙個codis節點僅在自己的記憶體中維護槽位與例項關係，那麼操維資訊如何在多個codis節點同步？-》使用zookeeper
當codis的codis dashboard改變槽位資訊的時候其他codis會監聽到zookeeper的變化，即時同步。
codis有自動均衡策略，當你新增乙個redis節點，codis會在機器空閒的時候觀察redis對應的slot數，不平衡自動進行遷移，遷移方式是會在原redis和新redis都保留槽位資訊，若要將key打進將要遷移或者正在遷移的舊槽位，此時codis處理機制是現將key強制遷移到新的redis節點，再告訴codis下次有新的key打入槽位，**到新節點。
codis不支援事務，單個集合總容量不要超過1m否則遷移會有卡頓感，在codis中增加了proxy當中轉層，所以在網路開銷上迴避單個redis的效能有所下降，所以會有些效能消耗，可以增加proxy數量來避免效能損耗(若是只有乙個proxy一般下降20%左右的效能)。
客戶端連線的redis**服務，本身實現了redis協議，表現和乙個原生的redis沒區別，對於乙個業務來說，可以部署多個codis-proxy，本身是無狀態的。
是codis的管理工具，支援刪除新增redis節點，新增刪除proxy節點，發起資料遷移等操作，本身自帶http server服務，會啟動乙個dashboard服務，可以直接在瀏覽器上觀察codis集群的執行狀態。
是codis專案維護的乙個redis分支，加入了slot的支援和原子的資料遷移指令，codis上層的proxy和config直郵和這個版本的redis互動才能正常使用。
依賴zookeeper存放資料路由表和codis-proxy節點的元資訊，codis-config傳送的資訊都會通過zookeeper同步到各個存活的codis-proxy
Codis集群測試
1 測試說明 1.1 背景 當前im架構設計與之前相比有很大不同，當前im將所有狀態資訊儲存在資料層，它的設計假設是資料層高可用，高效能，可擴容 目前im資料層採用redis集群codis搭建。1.2 目標 以下測試針對單機redis和codis進行測試，通過對比分析得到im資料層的擴容能力，測試出...
codis集群相關
codis是乙個分布式redis集群解決方案，對於上層的應用來說,連線到codis proxy和連線原生的redis server沒有明顯的區別。jiagou圖示如下 codis redis 是基於開源redis修改了部分內容，完全相容開源redis，分為多組主備 客戶端都通過proxy連線進來 z...
Codis使用入門
首先嚴重吐槽 在使用coids遇到無數坑 坑 坑 首先對於不熟悉linux系統的同學也是一大坑爹的貨各種命令不知道邊使用邊查詢 好吧對於熟悉同學先繞道 對於codis的效能和高可用性在日後測試過程中在分享。下面是搭建環境由於沒有linux機器就是有vm搭建軟體版本 vmware workstatio...