你看到的未读消息提醒是真的吗？【分布式锁解决的问题】

消息和未读不一致的原因

那么在即时消息场景中，究竟会有哪些情况导致消息和未读数出现“不一致”的情况呢？要搞清楚这个问题，我们要先了解两个涉及未读数的概念：“总未读”与“会话未读”。我们分别来看看以下两个概念。

  • **会话未读：**当前用户和某一个聊天方的未读消息数。比如用户 A 收到了用户 B 的 2 条消息，这时，对于用户 A 来说，他和用户 B 的会话未读就是“2”，当用户 A 打开和用户 B 的聊天对话页查看这两条消息时，对于用户 A 来说，他和用户 B 的会话未读就变成 0 了。对于群聊或者直播间来说也是一样的逻辑，会话未读的对端只不过是一个群或者一个房间。
  • **总未读：**当前用户的所有未读消息数，这个不难理解，总未读其实就是所有会话未读的和。比如用户 A 除了收到用户 B 的 2 条消息，还收到了用户 C 的 3 条消息。那么，对于用户 A 来说，总未读就是“5”。如果用户查看了用户 B 发给他的 2 条消息，这时用户 A 的总未读就变成了“3”。

从上面的概念我们知道，实际上总未读数就是所有会话未读数的总和，那么，在实现上是不是只需要给每个用户维护一套会话未读就可以了呢？

image-20210817153937426

保证未读更新的原子性

那么，在分布式场景下，如何保证两个未读的“原子更新”呢？一个比较常见的方案是使用一个分布式锁来解决，每次修改前先加锁，都变更完后再解开。

分布式锁

分布式锁的实现有很多，比如，依赖 DB 的唯一性、约束来通过某一条固定记录的插入成功与否，来判断锁的获取。也可以通过一些分布式缓存来实现，比如 MC 的 add、比如 Redis 的 setNX 等。具体实现机制，我这里就不细讲了，在我们的实战课程中，我们会有相应的代码体现。

不过，要注意的是，分布式锁也存在它自己的问题。由于需要增加一套新的资源访问逻辑，锁的引入会降低吞吐；同时对锁的管理和异常的处理容易出现 Bug，比如需要资源的单点问题、需要考虑宕机情况下如何保证锁最终能释放。

支持事务功能的资源

除了分布式锁外，还可以通过一些支持事务功能的资源，来保证两个未读的更新原子性。

事务提供了一种“将多个命令打包， 然后一次性按顺序地执行”的机制， 并且事务在执行的期间不会主动中断，服务器在执行完事务中的所有命令之后，才会继续处理其他客户端的其他命令。

比如：Redis 通过 MULTI、DISCARD 、EXEC 和 WATCH 四个命令来支持事务操作。

比如每次变更未读前先 watch 要修改的 key，然后事务执行变更会话未读和变更总未读的操作，如果在最终执行事务时被 watch 的两个未读的 key 的值已经被修改过，那么本次事务会失败，业务层还可以继续重试直到事务变更成功。

依托 Redis 这种支持事务功能的资源，如果未读数本身就存在这个资源里，是能比较简单地做到两个未读数“原子变更”的。

但这个方案在性能上还是存在一定的问题，由于 watch 操作实际是一个乐观锁策略，对于未读变更较频繁的场景下（比如一个很火的群里大家发言很频繁），可能需要多次重试才可以最终执行成功，这种情况下执行效率低，性能上也会比较差。

原子化嵌入脚本

那么有没有性能不错还能支持”原子变更“的方案呢？

其实在很多资源的特性中，都支持”原子化的嵌入脚本“来满足业务上对多条记录变更高一致性的需求。Redis 就支持通过嵌入 Lua 脚本来原子化执行多条语句，利用这个特性，我们就可以在 Lua 脚本中实现总未读和会话未读的原子化变更，而且还能实现一些比较复杂的未读变更逻辑。

比如，有的未读数我们不希望一直存在而干扰到用户，如果用户 7 天没有查看清除未读，这个未读可以过期失效，这种业务逻辑就比较方便地使用 Lua 脚本来实现“读时判断过期并清除”。

原子化嵌入脚本不仅可以在实现复杂业务逻辑的基础上，来提供原子化的保障，相对于前面分布式锁和 watch 事务的方案，在执行性能上也更胜一筹。

不过这里要注意的是，由于 Redis 本身是服务端单线程模型，Lua 脚本中尽量不要有远程访问和其他耗时的操作，以免长时间悬挂（Hang）住，导致整个资源不可用。

留一个思考题：类似 Redis+Lua 的原子化嵌入脚本的方式，是否真的能够做到“万无一失”的变更一致性？比如，执行过程中机器掉电会出现问题吗？

redis在执行lua脚本过程中如果发生掉电，是可能会导致两个未读不一致的，因为lua脚本在redis中的执行只能保证多条命令会原子执行，整体执行完成才会同步给从库并写入aof，所以如果执行过程中掉电，会直接导致被中断的后面部分的脚本得不到执行。当然， 实际情况中这种概率非常小。作为兜底的方案，可以在未读变更时如果会话比较少，可以获取一次全量的会话未读来覆盖总未读，从而有机会能得到最终一致

redis对于脚本执行并没有做到真正的事务性，lua脚本在redis中的执行只能保证多条命令会原子执行，整体执行完成才会同步给从库并写入aof，所以如果执行过程中掉电，会直接导致被中断的后面部分的脚本得不到执行。lua脚本中可以增加一些修复机制，比如会话比较少的话就聚合一次会话来覆盖总未读。