【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 
故事
小白是一个创业公司的技术负责人，创业初期，用户量很少，小白非常愉快的使用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
来源：oschina
链接：https://my.oschina.net/u/2244142/blog/1608587