技术架构入门：开源商城中间件（MySQL、Redis）作用与选型

一、MySQL 在 ZKmall 里的核心角色和选型讲究

1. 核心角色：电商数据的 “压舱石”

• 存商品数据：商品叫啥名、卖多少钱、有啥特点，还有 SKU 的颜色尺码、库存数量这些，都存在这儿。而且它还能应付复杂的查询，比如 “按类别挑 + 选价格范围 + 按销量排” 这种组合条件；
• 管订单数据：订单从创建、付钱、发货到签收的整个过程都记着，想按用户、时间、状态查都行；
• 存用户和商家信息：用户的注册信息、收货地址、会员等级，商家的资质、店铺信息、结算账户，全在这儿存着；
• 记交易流水：每笔支付的金额、用啥付的、啥时候付的、成没成，都记下来，给财务对账当依据。

2. 为啥选 MySQL？

• 数据一致性靠谱：电商交易最讲究 “要么都成，要么都不成”，比如 “下单减库存”，MySQL 的事务特性就保证了这点，不会出半拉子事儿；
• 查询能力强：复杂的 SQL 查询都能搞定，像多表关联、算总数平均数这些，电商里查商品、统计订单都用得上；
• 周边工具多：不管是管理工具（像 MySQL Workbench、Navicat），还是备份办法（比如 mysqldump、xtrabackup）、监控系统（比如 Prometheus+Grafana），都很齐全，开发和维护起来省事儿；
• 高可用方案多：主从复制、主主复制、MGR 集群这些都支持，不管电商平台规模大小，都能找到合适的稳定方案。

3. ZKmall开源商城 对 MySQL 的优化招数

• 分库分表：
  按业务把库分开，比如商品库、订单库、用户库，不让一个库太累；
  按商户 ID 的哈希值分库，比如 10 个库，商户 ID 除以 10 余几就放哪个库，免得一个商户的数据太多撑着；
  订单表按年月分开，像 order_202301、order_202302，查历史订单就快多了。
• 优化索引：
  给经常查的字段加复合索引，比如商品表的 category_id、status，订单表的 user_id、create_time；
  也不能加太多索引，每个表最多 5 个，不然写数据的时候维护索引太费劲儿。
• 盯慢查询：
  设个 slow_query_log，把执行时间超过 1 秒的 SQL 记下来，定期看看咋回事，该加索引的加索引，该改查询逻辑的改逻辑。有个电商平台就靠这招，把商品列表页的加载时间从 2 秒压到了 0.5 秒。

二、Redis 在 ZKmall开源商城 里的核心角色和选型讲究

1. 核心角色：电商系统的 “加速器”

• 缓存高频数据：热门商品的详情、用户的购物车、促销活动规则这些，都放 Redis 里，少去麻烦 MySQL。有个卖衣服的商城，把爆款连衣裙放 Redis 后，访问响应时间从 300 毫秒降到 20 毫秒，每秒能处理的请求从 500 涨到 5000；
• 管登录状态：用户登录的 Token、权限信息都存在这儿，手机、电脑、小程序上登录状态能同步，不用反复登录；
• 搞分布式锁和限流：
  秒杀、减库存的时候，用 SETNX 命令搞个互斥锁，防止多个人同时操作超卖了；
  用 Redis 加 Lua 脚本搞令牌桶算法，限制接口访问次数，比如 “一分钟最多 100 次”，别让太多请求把系统压垮。

2. 为啥选 Redis 而不是 Memcached？

• 数据结构多：String、Hash、List、Set、Sorted Set 这些都支持，不同场景都能用。比如用 Hash 存商品信息，字段名是属性，字段值是属性值；用 Sorted Set 做热门商品排行榜，分数就是销量；
• 能存盘：RDB 快照和 AOF 日志两种方式都能存数据，服务器重启了也能恢复，靠谱；
• 高可用方案全：主从复制、哨兵模式、Cluster 集群都支持，不管平台大小，都能保证稳定；
• 能原子操作：用 Lua 脚本能把几个操作弄成一个原子操作，比如 “查完就删”，业务逻辑简单了，性能也高了。

3. ZKmall开源商城 对 Redis 的优化招数

• 缓存分层次：
  一级缓存用本地缓存（Caffeine）存那些访问特别频繁的数据，比如顶部导航菜单，少去问 Redis 要；
  二级缓存用 Redis 集群存热门商品、用户会话这些，过期时间设得合理，比如商品详情存 5 分钟，购物车存 1 天；
  商品信息一改，本地缓存和 Redis 缓存一起清掉，保证数据一样。
• 内存管好：
  设成 allkeys-lru 策略，最近最少用的先删掉，别让内存满了；
  用 INFO memory 命令看看内存用得咋样，定期把那些好久没人碰的数据清掉，比如 30 天没访问的用户会话。
• 集群部署：
  用 Redis Cluster 集群（16384 个槽位），能横向扩展读写能力。有个卖 3C 产品的商城，双十一的时候搞了 3 主 3 从的 Redis Cluster，缓存每秒能处理的请求从 1 万涨到 5 万，顶住了高峰。

三、MySQL 和 Redis 咋配合干活

1. 查数据的时候

• 应用先去问 Redis 有没有；
• 有就直接拿回来，眨眼的功夫（大概 1 毫秒）；
• 没有就去问 MySQL（大概 200 毫秒），拿到后存到 Redis 里，设个 5 分钟过期，再返回给用户；
• 那些大家常看的商品，就一直在 Redis 里待着，少去烦 MySQL。

2. 改数据的时候

• 应用先去改 MySQL 里的数据；
• 马上把 Redis 里的缓存删了，不直接改，免得并发出问题；
• 下次有人查，Redis 里没有，就去 MySQL 拿新数据再存到 Redis 里。

四、根据业务规模咋选配置？

1. 刚起步（每天订单不到 1000，用户不到 10 万）

• MySQL：单台服务器（8 核 16G+500G SSD），用 InnoDB 引擎，1 主 1 从复制用来备份；
• Redis：单节点（4 核 8G），只缓存热门商品和用户会话，不存盘（丢了能从 MySQL 找回来）；
• 成本：云服务器一个月大概 3000 块，能顶住每秒 500 次请求。

2. 发展中（每天订单 1000-1 万，用户 10 万 - 100 万）

• MySQL：1 主 2 从的集群，按业务分库（商品库、订单库、用户库），把大表拆开，比如商品评论单独放一个库；
• Redis：1 主 2 从的哨兵模式，开 RDB 存盘，内存扩到 16G，多缓存点东西，比如促销规则、库存快照；
• 成本：云服务器一个月大概 1.5 万，能顶住每秒 2000 次请求。

3. 成熟了（每天订单超过 1 万，用户超过 100 万）

• MySQL：
  按商户 ID 分库，按时间分表，用 ShardingSphere 中间件；
  主从集群换成 MGR 集群（多主多写），写数据更快；
  加分布式缓存（比如 MyCat），热点数据访问更快。
• Redis：
  Cluster 集群（3 主 3 从），每个节点内存 64G；
  开 AOF 存盘（每秒同步一次），数据靠谱；
  热门数据放主集群，冷数据放从集群，冷热分开。
• 成本：云服务器一个月大概 5 万，能顶住每秒 1 万次请求，应付百万级并发没问题。

五、实战例子：某跨境电商平台的中间件优化

• MySQL 方面：
  把原来一个库拆成商品库、订单库、用户库、营销库 4 个；
  订单表按月份分，比如 order_202301、order_202302，每个表的数据从 5000 万降到 200 万；
  给商品表加了 category_id+status+price 的复合索引，商品列表页加载时间从 2 秒降到 0.5 秒。
• Redis 方面：
  搞了 3 主 3 从的 Cluster 集群，内存从 8G 扩到 64G；
  商品详情、购物车、促销规则这些全缓存起来，缓存命中率从 40% 提到 85%；
  用本地缓存（Caffeine）存顶部导航菜单，少访问 30% 的 Redis。
• 配合优化：
  查数据 90% 走 Redis，改数据直接改 MySQL 然后删缓存，读写分开；
  商品一改，先删 Redis 缓存，再用消息队列慢慢刷新，不让缓存被击穿。