对redis高可用、高并发、高性能的理解

概述

之前对“高性能、高可用、高并发”，只知其名不知其意，直到在知乎上看到redis系列文章，才豁然开朗，对redis的三高可以这么理解。

说明

• 高性能，指的是查询快。
  • redis是c语言实现，与其他语言相比，在实现语言层面性能高；redis是内存数据库，而传统的关系型数据库是磁盘文件读写，所以redis读写快；单线程，无上下文切换损耗，也不需要线程间同步，在单核cpu上，性能高，如果服务器是多核cpu，可以开启多个进程的单线程redis实例；基于以上原因，才达到了官网所说的，即使pc都支持QPS>10w/s的查询。
• 高可用（High Availability），高可用指的是在节点故障时，服务仍然能正常运行或者进行降级后提供部分服务；
  • 单点redis，redis是内存数据库，在遇到断电或者重启时，数据能恢复吗？当然能。redis提供了两种持久化方式AOF/RDB，AOF是Append Of File，redis的修改命令（hset、set）会写入文件中，在恢复数据时，从头执行一遍命令就恢复了数据了，这种数据最全，但是恢复时间长。RDB是Redis DataBase，redis会定时备份数据，这是默认的持久化方式，但是因为是定时备份所有数据会有部分缺失。
  • master-slave，如果单点redis遇到故障怎么办？redis提供master-slave/sentinel/cluster高可用方案，master-slave是常见的复制（Replication） 方案，一个master，多个slave，就是俗称的主从复制，master用来接收请求，slave备份master数据，冗余了数据，但master-slave有个缺点，master 故障后，slave不会自动切换为master，必须人为干预，sentinel就是用来解决这个问题的
  • sentinel，这种方案在master-slave的基础上，多了sentinel[ˈsentɪnl]，sentinel汉语意思是哨兵，哨兵监测master及所有的slave状态（心跳），如果master故障，sentinel会组织slave选举新的master，并通知客户端，从而实现可用性，但是单master毕竟能力有限（查询最大10w/s），如果超过这个极限，怎么办？我们会想，如果有多个master就好了，这就是集群
• 高并发，redis cluster
  • redis集群有2个TCP 端口，一个用来伺服客户端，比如常见的6379，另外一个对6379+10000=16379，作为“high”端口，high端口用来节点间通信、失败监测、故障转移授权、配置更新，high端口与数据端口差值必须是固定的10000。redis集群对数据做了分片，redis数据分片没有采用一致性哈希（consistent hash），而是使用了hash slot，redis集群一共有16384（2的14次方）个槽，key对16384取模分配，比如A、B、C三个节点，
    节点A 哈希槽（ 0 ~ 5500）
    节点 B 哈希槽（5501 ~ 11000）
    节点 C哈希槽（ 11001 ~ 16383）
    增加节点D，那么就要将A、B、C的部分数据迁移到D上；如果删除A，那就要将A的数据迁移到B、C上，然后才能完全删除A。为了增加可用性，每个节点使用主从复制，比如A1、B1、C1，当B节点故障时，集群会将B1设置为新master，当B1也故障时，集群就真down了。

总结

如果理解了redis的高可用、高性能、高并发，那么其他组件的三高也容易理解了，比如mysql的主从复制就是为了高可用、如果主从复制读写分离那么又多满足了一项–高性能，同时也有高并发的提升。平时，得多思考，保持一颗敏感的心。

9年全栈开发经验，请关注个人公众号