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