Elasticell-緣起

故事

小白是一個創業公司的技術負責人，創業初期，用戶量不多，小白很是愉快的使用Redis來作緩存，系統上線，運行良好，系統響應快速。

過了兩天瀟灑日子，小白在睡夢中被一震手機短信提示音吵醒。小白看了下短信內容：「臥槽，系統響應時間增大，Redis機器掛掉了，什麼狀況？」，爬起來恢復了Redis機器，系統恢復正常。

次日，到公司，小白不想半夜被吵醒，因而作出了架構變動，把Redis從單機修改成Master-Slave結構，而且修改業務代碼。改完以後，好長一段時間，小白再沒有被Redis的問題給騷擾到，全身心的投入到業務開發中。

業務越作越複雜，用戶量愈來愈多，系統的問題也愈來愈多，小白的好日子又到頭了，老闆找到小白：「最近總有客戶說系統響應慢，你去查一下，儘快修復」。小白當即一頭扎進問題，各類分析，最後一看Redis，CPU一直處於100%。小白心想，單個Redis是支撐不了目前的業務了，小白內心大概估算了了下業務的發展規模，把架構修改成了4套Redis，每套都是Master-Slave結構，而後快速修改了業務代碼，根據key的hash來選擇Redis，「OK，完工！」，順利完成了老闆交代的任務，繼續全身心的投入到業務開發中。

又過了一段時間，業務發展迅猛，用戶量又有了很大的提高，以前的問題又出現了，老闆叫來了小白：「這個問題不是已經解決了麼？怎麼沒多久又出現了，儘快修復！」。小白又回去看了一下4套Redis機器：「哎，業務發展太快了，加機器吧」，可是內心冒出了兩個問題驚出一身冷汗：

• 加了機器，原來的選擇Redis算法的輸入不對了，須要搬遷數據
• 加機器的時候，確定須要停服務

小白花了兩天時間完成了數據遷移程序，而且和老闆彙報：「老闆，我須要中止服務2個小時才能修復這個問題」，老闆一聽，頓時臭罵一頓：「夜裏1點開始，下不爲例」。小白熬了一個通宵，終於把Redis機器從4臺擴展到16臺。

通過此次，小白長了個心眼，這樣下去不是辦法，每次都要擴容，心太累，得想一些解決方法，否則要坑死了。正在這個時候業界大神劉琦和黃東旭開源了Codis解決方案，小白一看：「我靠，就它了，太他媽合適了」，因而乎三下五除二的把現有的Redis架構變動爲Codis方案。

方案變動後，小白每天簡直是「吃嘛嘛香」，在用戶量後續幾回提高的狀況下，小白屢次在出現問題以前很輕鬆的實施了Redis的擴容，心智負擔下降了不少。小白爲本身的這個架構變動感到很是欣慰。

慢慢的公司的業務壯大了，分支項目愈來愈多，小白和小夥伴們推薦了Codis方案，公司也成立了專門的運維部門，小白也把維護Codis的任務轉交給了運維小夥伴小胖，一切都很完美。

過了一年，公司的項目雨後春筍般的發展了起來，Codis的實例也愈來愈多，小胖慢慢的變成了一個Codis的維護專家，本身編寫一些腳本解決了一些經常使用運維問題，日子過得還算滋潤。

可是好景不長，一個黑天鵝時間發生了，機房網絡出現故障，Codis集羣出現了Redis主從的腦裂問題，這下小胖掉進了深坑。小胖和小白一塊兒花費了很長的時間恢復腦裂，從新加載緩存數據，臨時恢復了環境，影響生產環境超過8個小時，固然免不了被老闆一頓臭罵。小白心想：「黑天鵝事件，概率過小，先無論它，看看啥時候Redis官方能有個解決方案」。

又過了幾年，因爲原先的服務器比較廉價，服務器常常損壞，時常致使Redis的Master機器出現問題，又帶來了一些問題：

• Slave和Master存在數據不一致的時間窗口
• 有業務開始把Redis做爲可靠存儲

小白和小胖總結了一下目前的狀況，認爲目前Codis解決了Redis的分佈式部署的問題，可是仍是有一些問題是沒有解決的，兩人總結了下需求：

• 支持持久化存儲
• 提供強一致
• 具有自動化的擴縮容能力（免運維，運維只負責增長機器）
• 具有自動化的Rebalance的能力
• 兼容Redis協議
• 高可用

Elasticell閃亮登場

Elasticell就是解決小白和小胖的終極方案，這是一個開源的解決方案，有興趣的朋友請訪問github