# 137. 商品详情页动态渲染系统：为什么是 twemproxy+redis 而不是 redis cluster？

# LVS 那块不讲解

LVS+KeepAlived 负载均衡、MySQL+Atlas 分库分表，不讲解了，很鸡肋

原因：单课，聚焦，围绕一个主题去讲解，太发散了以后，什么都讲，没有围绕主题去讲解，意义不是太大

本课主题：商品详情页系统，亿级流量大电商，核心的东西

随着课程不断讲解，可能会有 10% 的出入，砍掉或者调整一些细枝末节，大的思路是 ok 的，不会改变的

之前讲解过 redis cluster，那么他的优缺点如下

读写请求全部落到主实例上的，如果要扩展写 QPS，或者是扩展读 QPS，都是需要扩展主实例的数量，从实例就是一个用做热备 + 高可用 2. 不好跟 nginx+lua 直接整合

lua->redis 的 client api，但是不太支持 redis cluster，中间就要走一个中转的 java 服务 3. 不好做树状集群结构

比如 redis 主集群一主三从双机房架构，redis cluster 不太好做成那种树状结构 4. 优点就是方便

相当于是上下线节点、集群扩容、运维工作、高可用自动切换，比较方便

twemproxy+redis 做集群，redis 部署多个主实例，每个主实例可以挂载一些 redis 从实例，如果将不同的数据分片写入不同的 redis 主实例中，twemproxy 这么一个缓存集群的中间件

就是最基本的多个 redis 主实例，数据落到哪一个实例上是 twemproxy 这个中间件来决定的，java/nginx+lua 客户端，是连接 twemproxy 中间件的。每个 redis 主实例就挂载了多个 redis 从实例，高可用 -> 可以使用哨兵

redis cluster 读写都要落到主实例的限制，你自己可以决定写主，读从，等等 3. 支持 redis cli 协议，可以直接跟 nginx+lua 整合 4. 可以搭建树状集群结构

就是看你的架构中是否能容忍 redis cluster 的前 3 个问题