Redis 目前绝对算是当前市场的宠儿，大到 BAT，小到初创公司都在使用。一说到 Redis，我们就会想到它的高性能、数据结构丰富、API 功能强大、高可用性以及架构可伸缩等特点。正是这些特点，让 Redis 受到越来越多的关注。

近期，小悦对 Redis 发展历程的见证者之一--朱文潇老师进行了简短的专访。

嘉宾介绍

朱文潇 ，大型互联网公司 8 年 Redis 运维实战经验，多次以核心身份主导 Redis 框架方案设计及落地实施，对 Redis 服务有深刻理解，对多种 Redis 实现方案都有独到的见解。

1 大学专业是？为什么选择从事计算机相关的工作？

大学专业也是计算机专业，初中开始就对计算机技术充满兴趣，刚毕业时也是互联网蓬勃发展的时期，机缘巧合从事计算机行业，但是刚进公司从事的工作处于技术边缘，兴趣、热爱及本职工作的出色完成，得到公司领导的赏识，逐步进入核心技术团队。生活总不是一帆风顺的，低落时要坚定信念，成长时要抓住机遇。

2 什么机缘巧合接触 Redis 的？

在公司初期频繁的人事调动，我逐渐变成了“老员工”，恰巧这个时段接管的 Redis 服务最多，在此期间查阅了很多 Redis 资料去解决实际工作中遇到的问题，机遇让我慢慢从 Redis “小白”变成了身边最熟悉 Redis 的那个人。

3 在工作这 8 年，生产环境使用过哪些 Redis 架构？都有哪些优缺点？踩到过哪些坑？

接触的架构很多，市面上大多数架构都有接触过，比如：

1）Redis 主从：可以快速提供服务，客户端与服务端直连，支持所有 Redis 的原生命令，可以最大程度展现 Redis 的高并发特性，那些对高可用要求不高的应用可以使用，然而高可用也是其主要缺陷。前段时间在“悦专栏”的邀请下，根据我的一些经验，也写了有关 Redis 主从的文章，感兴趣的可以点击跳转。

2）基于 Sentinel 的 Redis 高可用：一种完善的高可用方案，可以实现自动切换，架构设计较为简单；但是高可用服务依赖于客户端与 Sentinel 的交互，客户端需要额外的优化更新，同时最大的瓶颈在于集群扩容较繁琐，往往还需要在停服的场景下才能保证数据的准确性。关于 Sentinel 的更多介绍以及我在维护 Sentinel 这些年踩了那些坑，可以跳转到之前的 Sentinel 文章。

3）Codis 集群高可用方案：一款分布式缓存高可用集群产品，提供了配套的客户端，提供了动态数据迁移，内置高可用方案，产品设计解决了运维大部分痛点；同样，如果想阅读更多关于 Codis 的内容，可以点击我之前出的一篇文章：Codis 集群高可用解决方案。但是有一个集群的通病，就是部分原生命令不支持，这样很多强依赖 Redis 的中间件无法使用，另外 Codis 已经不提供持续更新，当产品出现巨大缺陷时，只能选择放弃。

4）Redis Cluster 集群高可用方案：官方推出的集群方案，用户不需要过度关心服务端本身的架构，内置高可用及分布式存储方案，而且对于原生命令的支持比市面上其他集群表现得都更为出色。从 Redis 2.X 到 Redis 3.X 以上版本需要投入很多测试，整体的运维技术也有很大的变化，需要不断的研究、不断的学习，这也是对运维人员的考验。

4 所维护的集群最大 QPS 是多少？有哪些典型的业务使用了 Redis？

所维护的集群最大 QPS 为 300W。Redis 数据结构丰富、并发能力出色，典型场景也是跟这些特性相关，比如抢购、排行榜这些高并发的场景，此外 Redis 还可以当队列使用，发布订阅的功能也在很多场景下被使用。

5 转管理岗位后工作重心的变化怎样？

转管理岗后，不但要打磨自己的技术，还要提升团队的整体实力，小锅炒菜和大锅炒菜的区别，大锅菜并不好炒。

6 推荐一些 Redis 的学习资料。

1）Redis 源代码并不长，有能力的一定要好好欣赏一下作者的代码艺术；

2）付磊、张益军两位老师编写的《Redis 开发与运维》，有原理解读，有实战经验，值得一看；

3）Redis 社区活跃度比较高，尽可能多去看一些 Redis 官方发布的内容，多参与社区讨论，往往有不同层次的理解。

相关阅读