《Redis复制与可扩展集群搭建》看后感

研读infoQ上《Redis复制与可扩展集群搭建》(http://www.infoq.com/cn/articles/tq-redis-copy-build-scalable-cluster)后，思考后，写下这篇看后感。

文章主要写了四点，

1. 对现有的Redis主从复制缺陷的思考，以及提出的主动复制解决思路。

2. 对动态扩容的思考

3. Redis复制改进思路

4. Redis与MySQL整合思路

在下只对1,2,4这三点说下感受。

针对第一点，目前我们知道Redis主从的实现，以及持久化的实现还不是非常完美。文章也说了持久化虽然有三种形式:快照，AOF以及VM,但是相对较好的只有 快照与AOF。主从复制过程中，一旦从库与主库失去连接后，就得重新全部同步一次。这个时候就需要主库做快照。在数据量非常大并写操作频繁的时候，主库做快照，无疑会对IO，以及内存有影响。所以作者针对这一点，提出主动复制的解决思路，就是不让Redis自己同步数据，而是我们在应用层向不同的Redis的实例写重复数据来达到数据多份的目的。虽然能够避免上面说的问题，同时也带来了数据一致性的问题。不管是针对数据一致性而采用的取多份再比较的方式还是其他更复杂的方式都会给应用层read与write带来复杂。所以针对这一点，我的意见是，Redis能干什么就用来干什么，不要轻意添加架构的复杂度。既然Redis现在在主从同步主面与持久化方式还不完善，那么现在就在一些小应用以及一些不太重要的应用上使用Redis的持化久与同步这些特性，对于那些非常重要的应用还是将Redis当Cache用比较好。除非公司有非常强的技术实力(sina,taobao,alibaba等)可以应对任何潜在的危险。如果现在轻意的采用上面所说的主动复制的方式，复杂不说，也不好针对Redis日后的更新做响应。万一哪一天，Redis可以非常完美的实现主从同步与持久化，应用层的主动复制要不要去掉？如果现在只在一些非重要的应用采用Redis本身的特性，不仅可以为公司积累技术经验，也为以后更好的使用Redis特性留下伏笔，也不会整天担心Redis出现问题而没有技术实力解决。