集群版Redis和Gossip协议
 单实例的由于本质上只有一台Master作为存储，就算机器为128GB的内存，一般建议使用率也不要超过70%-80%，所以最多使用100GB数据就已经很多了，实际中50%就不错了，以为数据量太大也会降低服务的稳定性，因为数据量太大意味着持久化成本高，可能严重阻塞服务，甚至最终切主。 如果单实例只作为缓存使用，那么除了在服务故障或者阻塞时会出现缓存击穿问题，可能会有很多请求一起搞死MySQL。 如果单实例作为主存，那么问题就比较大了，因为涉及到持久化问题，无论是bgsave还是aof都会造成刷盘阻塞，此时造成服务请求成功率下降，这个并不是单实例可以解决的，因为由于作为主存储，持久化是必须的。 所以我们期待一个多主多从的Redis系统，这样无论作为主存还是作为缓存，压力和稳定性都会提升，尽管如此，笔者还是建议： 如果你一意孤行，那么要么坑了自己，要么坑了别人。
要支持集群首先要克服的就是分片问题，也就是一致性哈希问题，常见的方案有三种： 客户端分片：这种情况主要是类似于哈希取模的做法，当客户端对服务端的数量完全掌握和控制时，可以简单使用。 中间层分片：这种情况是在客户端和服务器端之间增加中间层，充当管理者和调度者，客户端的请求打向中间层，由中间层实现请求的转发和回收，当然中间层最重要的作用是对多台服务器的动态管理。 服务端分片：不使用中间层实现去中心化的管理模式，客户端直接向服务器中任意结点请求，如果被请求的Node没有所需数据，则像客户端回复MOVED，并告诉客户端所需数据的存储位置，这个过程实际上是客户端和服务端共同配合，进行请求重定向来完成的。 （编辑：通化站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
