三、Codis在生产环境中的使用的经验和坑们
来说一些 tips，作为开发工程师，一线的操作经验肯定没有运维的同学多，大家一会可以一起再深度讨论。
关于多产品线部署：很多朋友问我们如果有多个项目时，codis如何部署比较好，我们当时在豌豆荚的时候，一个产品线会部署一整套codis，但是zk共用一个，不同的codis集群拥有不同的product name来区分，codis本身的设计没有命名空间那么一说，一个codis只能对应一个product name。不同product name的codis集群在同一个zk上不会相互干扰。
关于zk：由于Codis是一个强依赖的zk的项目，而且在proxy和zk的连接发生抖动造成sessionexpired的时候，proxy是不能对外提供服务的，所以尽量保证proxy和zk部署在同一个机房。生产环境中zk一定要是>=3台的奇数台机器，建议5台物理机。
关于HA：这里的HA分成两部分，一个是proxy层的HA，还有底层Redis的HA。先说proxy层的HA。之前提到过proxy本身是无状态的，所以proxy本身的HA是比较好做的，因为连接到任何一个活着的proxy上都是一样的，在生产环境中，我们使用的是jodis，这个是我们开发的一个jedis连接池，很简单，就是监听zk上面的存活proxy列表，挨个返回jedis对象，达到负载均衡和HA的效果。也有朋友在生产环境中使用LVS和HA Proxy来做负载均衡，这也是可以的。 Redis本身的HA，这里的Redis指的是codis底层的各个server group的master，在一开始的时候codis本来就没有将这部分的HA设计进去，因为Redis在挂掉后，如果直接将slave提升上来的话，可能会造成数据不一致的情况，因为有新的修改可能在master中还没有同步到slave上，这种情况下需要管理员手动的操作修复数据。后来我们发现这个需求确实比较多的朋友反映，于是我们开发了一个简单的ha工具：codis-ha，用于监控各个server group的master的存活情况，如果某个master挂掉了，会直接提升该group的一个slave成为新的master。 项目的地址是：https://github.com/ngaut/codis-ha。
关于dashboard：dashboard在codis中是一个很重要的角色，所有的集群信息变更操作都是通过dashboard发起的这个设计有点像docker），dashboard对外暴露了一系列RESTfulAPI接口，不管是web管理工具，还是命令行工具都是通过访问这些httpapi来进行操作的，所以请保证dashboard和其他各个组件的网络连通性。比如，经常发现有用户的dashboard中集群的ops为0，就是因为dashboard无法连接到proxy的机器的缘故。
关于go环境：在生产环境中尽量使用go1.3.x的版本，go的1.4的性能很差，更像是一个中间版本，还没有达到production ready的状态就发布了。很多朋友对go的gc颇有微词，这里我们不讨论哲学问题，选择go是多方面因素权衡后的结果，而且codis是一个中间件类型的产品，并不会有太多小对象常驻内存，所以对于gc来说基本毫无压力，所以不用考虑gc的问题。
关于队列的设计：其实简单来说，就是「不要把鸡蛋放在一个篮子」的道理，尽量不要把数据都往一个key里放，因为codis是一个分布式的集群，如果你永远只操作一个key，就相当于退化成单个Redis实例了。很多朋友将Redis用来做队列，但是Codis并没有提供BLPOP/BLPUSH的接口，这没问题，可以将列表在逻辑上拆成多个LIST的key，在业务端通过定时轮询来实现除非你的队列需要严格的时序要求），这样就可以让不同的Redis来分担这个同一个列表的访问压力。而且单key过大可能会造成迁移时的阻塞，由于Redis是一个单线程的程序，所以迁移的时候会阻塞正常的访问。
关于主从和bgsave：codis本身并不负责维护Redis的主从关系，在codis里面的master和slave只是概念上的：proxy会将请求打到「master」上，master挂了codis-ha会将某一个「slave」提升成master。而真正的主从复制，需要在启动底层的Redis时手动的配置。在生产环境中，我建议master的机器不要开bgsave，也不要轻易的执行save命令，数据的备份尽量放在slave上操作。
关于跨机房/多活：想都别想。。。codis没有多副本的概念，而且codis多用于缓存的业务场景，业务的压力是直接打到缓存上的，在这层做跨机房架构的话，性能和一致性是很难得到保证的
关于proxy的部署：其实可以将proxy部署在client很近的地方，比如同一个物理机上，这样有利于减少延迟，但是需要注意的是，目前jodis并不会根据proxy的位置来选择位置最佳的实例，需要修改。
四、对于分布式数据库和分布式架构的一些看法one more Thing）
Codis相关的内容告一段落。接下来我想聊聊我对于分布式数据库和分布式架构的一些看法。 架构师们是如此贪心，有单点就一定要变成分布式，同时还希望尽可能的透明:P。就MySQL来看，从最早的单点到主从读写分离，再到后来阿里的类似Cobar和TDDL，分布式和可扩展性是达到了，但是牺牲了事务支持，于是有了后来的OceanBase。Redis从单点到Twemproxy，再到Codis，再到Reborn。到最后的存储早已和最初的面目全非，但协议和接口永存，比如SQL和Redis Protocol。
NoSQL来了一茬又一茬，从HBase到Cassandra到MongoDB，解决的是数据的扩展性问题，通过裁剪业务的存储和查询的模型来在CAP上平衡。但是几乎还是都丢掉了跨行事务插一句，小米上在HBase上加入了跨行事务，不错的工作）。
我认为，抛开底层存储的细节，对于业务来说，KV，SQL查询关系型数据库支持）和事务，可以说是构成业务系统的存储原语。为什么memcached/Redis+mysql的组合如此的受欢迎，正是因为这个组合，几个原语都能用上，对于业务来说，可以很方便的实现各种业务的存储需求，能轻易的写出「正确」的程序。但是，现在的问题是数据大到一定程度上时，从单机向分布式进化的过程中，最难搞定的就是事务，SQL支持什么的还可以通过各种mysqlproxy搞定，KV就不用说了，天生对分布式友好。
于是这样，我们就默认进入了一个没有跨行）事务支持的世界里，很多业务场景我们只能牺牲业务的正确性来在实现的复杂度上平衡。比如一个很简单的需求：微博关注数的变化，最直白，最正常的写法应该是，将被关注者的被关注数的修改和关注者的关注数修改放到同一个事务里，一起提交，要么一起成功，要么一起失败。但是现在为了考虑性能，为了考虑实现复杂度，一般来说的做法可能是队列辅助异步的修改，或者通过cache先暂存等等方式绕开事务。
但是在一些需要强事务支持的场景就没有那么好绕过去了目前我们只讨论开源的架构方案），比如支付/积分变更业务，常见的搞法是关键路径根据用户特征sharding到单点MySQL，或者MySQLXA，但是性能下降得太厉害。
后来Google在他们的广告业务中遇到这个问题，既需要高性能，又需要分布式事务，还必须保证一致性:)，Google在此之前是通过一个大规模的MySQL集群通过sharding苦苦支撑，这个架构的可运维/扩展性实在太差。这要是在一般公司，估计也就忍了，但是Google可不是一般公司，用原子钟搞定Spanner，然后再Spanner上构建了SQL查询层F1。我在第一次看到这个系统的时候，感觉简直惊艳，应该是第一个可以真正称为NewSQL的公开设计的系统。所以，BigTable(KV)+F1(SQL)+Spanner(高性能分布式事务支持)，同时Spanner还有一个非常重要的特性是跨数据中心的复制和一致性保证通过Paxos实现），多数据中心，刚好补全了整个Google的基础设施的数据库栈，使得Google对于几乎任何类型的业务系统开发都非常方便。我想，这就是未来的方向吧，一个可扩展的KV数据库作为缓存和简单对象存储），一个高性能支持分布式事务和SQL查询接口的分布式关系型数据库，提供表支持。
