商城(4) 购物车的设计

购物车功能的痛点在于写操作过于频繁，所以取舍点主要在持久化方案。

一般的可以用mysql建表，一个用户对应一个购物车。那么用户的分布式唯一ID就可以作为主key，按用户表相同的规模对购物车分库分表。这里还要注意到商品和用户是多对多关系，最好用json只记录商品分布式ID和数量，然后根据商品ID再去ES里查。

实际上这样写操作压力还是很大，虽然走mysql索引不会锁表，但是为了这一个功能要付出庞大的数据库io开销是有些不划算的。另外可以考虑Redis，使用Hash数据结构，用户-商品-数量这么储存也非常合适。Redis使用集群+哨兵可用性很高，一般来说持久化足够了。

所以这里视业务规模而定，如果不在意io在意存储成本，选mysql。如果硬件没那么大的内存，选Redis。或者说你希望持久化一份到mysql，完全可以先写redis，然后写job定时同步，同步只同步那些update过的用户即可。

比较难设计的是购物车数量变化，系统当然不可能变化一次数量就写一次，这样非常容易导致请求过多。看过腾讯海量服务之道之后，应该知道分布式系统中，前端保护后端，后端不信任前端，所以对购物车商品变化这件事应该分级考虑设计。首先是前端，修改商品数量后不要立刻请求API，等待1-2秒以后，再用最终的修改数量请求，同时为了防止有人恶意调取API，后端也要做IP限流、数量合法性校验，最后再去Redis修改。