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

猜你喜欢

转载自my.oschina.net/u/2244142/blog/1608587
今日推荐