作者：小蒋
邮箱：wei_wei10@163.com
微信：wei_wei10
音频：https://xima.tv/1_jCsM3t?_sonic=0

【小蒋聊技术】关注技术成长，深挖业务价值。大家好，我是小蒋。

---

前言

上一节课我们搭建了电商全景地图，了解了电商有十大核心模块。这节课开始，我们要一个个深入拆解。

先从哪个模块开始呢？毫无疑问，一定是用户中心。为什么？因为它是电商的根基。没有用户，你东西卖给谁？对吧。

你可能会想，用户中心不就是注册、登录吗？这有啥好讲的？如果你也这么觉得，说明你可能还没真正做过业务。小蒋想告诉你，这里面的门道太多了。

大家想想，当你日活达到百万、千万的时候，会遇到什么问题？几亿用户数据怎么存？几十万同时登录怎么扛？这就是我们今天要解决的。

---

用户中心要解决什么问题？

用户中心是电商系统的入口，听起来简单，但要做的事情不少。

首先，用户怎么注册？手机号、邮箱、第三方账号，都得支持吧。其次，登录之后怎么证明你是你？这就是身份认证。还有，不同人看到的东西不一样，这叫权限管理。最后，用户还有等级、积分，这是会员体系。

但是，我一直在强调一句话：技术是手段，业务是目的。我们讲这些技术，到底是为了解决什么业务问题？大家一定要带着这个问题来听。

---

海量用户存储

先问大家一个问题：如果你现在有一千万用户，你会怎么存？

很多新手会说，一个MySQL表存着呗。没错，一百万数据时没问题。但是一千万呢？查询开始变慢了。更可怕的是写入高峰，数据库连接数被耗尽，直接崩溃。

这意味着什么？用户登录转圈十秒钟，直接就走人了。查询超时，体验极差。高峰期数据库崩溃，新用户都注册不了。想想看，这是不是都是业务问题？用户流失，直接影响收入。

所以我们得解决。怎么做？先做读写分离。大家知道，用户登录一次，可能浏览几十次商品，所以读请求是写请求的几十倍。我们用一主多从架构：主库写，从库读。

但这还不够。用户量继续涨怎么办？就得做分库分表。把用户数据按ID取模，分成一千零二十四个表，数据均匀分散。

听到这里，是不是觉得很简单？我告诉你，真正的坑还在后面。

首先，跨库查询怎么办？以前一条SQL搞定的事，现在要查多个库。查某时间段注册的用户？数据分散在各个分片，只能业务层聚合。

其次，分布式事务怎么办？用户注册后，可能同时在用户库、积分库、会员库插入数据。这里面涉及CAP理论，分布式系统无法同时满足一致性、可用性、分区容错性。实际落地时，要么用TCC模式，要么用可靠消息最终一致性。怎么处理？后续会单独开课讲。

不解决这个有什么损失？用户注册成功，但积分没加上，会员没开通。用户体验很差，会投诉。

还有数据迁移怎么办？几亿数据不可能停机迁移。用双写方案，Canal监听Binlog同步。扩容怎么办？一千零二十四个分片不够用，要扩到两千零四十八个，怎么迁移？

大家看，这就是我说的：海量用户存储，绝对不是一个分库分表就解决了的。里面有太多细节。

所以我一直强调：技术本身没有价值，能解决业务问题，技术才有价值。

---

认证设计

说完了存储，我们再说认证。用户登录后，系统怎么知道他是谁？

有两种主流方案。

第一种，Session。服务端生成Session ID存Redis，返回给客户端。优点是可以随时封号。缺点是多节点部署时Session同步麻烦，Redis挂了所有人都登出。

第二种，JWT。服务端用密钥生成令牌，包含用户信息，直接返回客户端。优点是无状态，水平扩展容易，APP、小程序都方便。缺点是令牌发出去就收不回。

选错了有什么损失？选Session，高峰期多节点部署用户频繁掉线。选JWT，账号被盗后无法立即封禁。

技术选型不是随便选的，要看业务场景。

这还不够，还有更复杂的。Token泄露怎么办？需要短期Token加刷新Token。强制登出怎么做？JWT收不回，得用黑名单。还有SSO单点登录，京东APP登录后，小程序不用再登录。这里面的门道，够单独开课了。

---

分布式ID

接下来聊聊分布式ID。

用户ID怎么生成？很多人说，用数据库自增ID啊，简单！但分库分表后，不同数据库实例ID会重复。A库有个ID等于1的用户，B库也有，这不全乱套了吗？

不这样做有什么损失？用户ID重复，导致数据混乱。竞争对手还能通过ID估算你每天新增多少用户，暴露商业机密。

常见方案有三种：雪花算法、UUID、数据库号段。电商一般用雪花算法，因为趋势递增对数据库索引友好。

但真正的复杂度是：时钟回拨怎么办？机器ID怎么分配？序列号溢出怎么办？这些问题都需要处理。

---

Redis分布式

刚才说Session存Redis，这只是冰山一角。

Redis在用户中心用得很多：登录态、验证码、限流、计数。

不做这些有什么损失？验证码无法验证，被黑客攻击系统挂掉。

复杂度在哪？集群怎么部署？缓存一致性怎么保证？大Key问题怎么办？热点Key怎么办？这些都是生产环境的坑。

---

Kafka消息队列

最后说说Kafka。

用户注册成功后，要发短信、加积分、开会员。同步调用的话，一个注册请求要等所有下游处理完，响应时间太长。

不这样做有什么损失？用户点击注册，页面转圈三十秒，直接流失。下游服务故障，注册失败。

解决方案是消息队列异步解耦。往Kafka发一条消息，下游各服务订阅处理。

复杂度在哪？消息顺序怎么保证？消息不丢怎么办？重复消费怎么办？消息积压怎么办？

---

总结

今天我们深入拆解了用户中心。五个核心技术点：海量用户存储、认证设计、分布式ID、Redis分布式、Kafka消息队列。

每一个点展开都是一门课。记住我们的核心理念：技术本身没有价值，能解决业务问题、帮企业降本增效创造收益，技术才有价值。

后续会单独开设Redis专题、Kafka专题、分布式事务专题，带大家深入每一个细节。

---

下期预告

第三课我们讲商品中心：亿级商品搜索与SKU管理。

搜索为什么能这么快？SKU和SPU有什么区别？价格计算有哪些坑？咱们下期揭晓。

---

思考题

你现在的项目里，用户ID用的是自增还是分布式ID？为什么这么选？

关注技术成长，深挖业务价值。有问题评论区见，我是小蒋，咱们下期见！