在构建高并发的外卖系统时，数据库选型直接决定了订单处理速度与数据一致性。平易客团队在研发初期曾对比过单机MySQL与分布式NewSQL，最终选择了MySQL 8.0 + Redis 6.x + TiDB混合存储方案——既保障了事务的ACID特性，又通过缓存层扛住了午晚高峰的流量洪峰。

核心存储架构：分层与职责

平易客的数据库设计遵循“冷热分离、读写分离”原则。热数据（最近3天的订单、配送员位置）全部放入Redis集群，使用String+Hash结构存储，单Key平均响应时间<2ms。冷数据（历史订单、用户评价）则存入TiDB，利用其自动分片能力将单表亿级数据查询控制在500ms以内。

关键参数与优化细节

1. MySQL主从配置：采用半同步复制，主库写入后等待至少一个从库确认，避免缓存雪崩时大量写请求直接击穿到TiDB。
2. Redis内存淘汰策略：选择allkeys-lru，配合TTL过期时间（订单缓存设为15分钟），确保高频访问的商品库存、跑腿系统路径数据始终在内存中。
3. TiDB分区表：按订单创建时间进行RANGE分区，每月自动新建分区，避免单个分区数据膨胀导致索引效率下降。

注意事项：分布式事务与数据一致性

在微信外卖订餐小程序中，用户下单涉及“扣库存→生成订单→更新跑腿系统配送单”三个步骤。平易客采用TCC（Try-Confirm-Cancel）模式，而非传统XA协议。例如，扣库存时先冻结商品数量，若支付超时则自动释放，配合消息队列（RabbitMQ）实现最终一致性。实测在高并发下，事务失败率从3.7%降至0.2%。

常见问题与解决方案

• Q：订单状态更新延迟，用户看到“待配送”但骑手已接单？
  A：将状态变更写入Redis时，同步推送至Kafka，由消费者异步写入MySQL。平易客在状态字段增加了版本号机制，避免覆盖式更新导致状态回退。
• Q：跑腿系统路径规划时，大量坐标点写入导致数据库IO飙升？
  A：改用GeoHash编码存储坐标，将二维数据转为一维字符串，写入效率提升40%。同时，在Redis中维护一个“热力点”缓存，仅当骑手偏离路线超过50米时才更新数据库。

总结

平易客的存储方案并非“万能药”，但通过分层策略与针对性调优，在日均百万级订单场景下，数据库CPU利用率稳定在65%以下。对于正在搭建外卖系统或跑腿系统的团队，建议优先评估自身业务的数据热点分布——如果订单集中在午晚两小时，Redis预加载+MySQL批量刷盘可能是性价比最高的选择。