同房间玩家操作的并发问题
现有问题（丢失更新/不可重复读）
- 现象： 玩家并发加入/离开时，前端显示玩家没有加入/离开。数据库中Game->Players没有被更新
- 现象： 玩家并发投票时，有的投票操作失败或投票结果没有出现。数据库中的voteHistory没有更新。
- 原因： GameService没有做并发处理。服务处理每个用户请求都会从数据库读取完整的Game+Players+votes，处理完后再写回数据。发生并发处理时，服务可能同时操作Game对象，回写时只有最后一个操作会生效，前面的回写会被覆盖。
并发处理的方法
- 线程锁
- 方法锁：@Syncronized
- 必须一个方法一个方法的加锁，且无法适用于响应式调用
- 对象锁：ReentrantLock
- 引入缓存，同一个Game share同一个对象，为这个对象加锁
- 无缓存的情况下，每个请求处理的Game都不是同一个对象，需要针对GameId设计锁
- 方法锁：@Syncronized
- 单线程
- 所有Game command都使用单线程处理，每个处理都要排队
- 为每个Game分配一个线程，同一GameId的command处理要排队
- 数据库锁
- 表锁? vs 条目锁? vs 字段锁?
- 悲观锁 vs 乐观锁（失败需要retry机制）
- All about lock
- kotlinx-coroutines-reactor ？？？ coroutines挂起避免线程阻塞
- 性能分析以及测试
有锁方案分析
目前的应用中，对Game数据的操作主要由玩家加入(Join)，离开(Leave)和游戏命令(Command)引发。这些操作都由读数据库开始，写数据库结束，如果操作失败则不会写数据库，读写操作数量基本持平。此外，由于只有同房间的游戏操作才会出现数据问题，所以频度较低。
综上，我们可以采用乐观锁。
- MongoDB乐观锁: 在Game中加入versionId并在写入数据时使用原子操作findAndModify。
- java方法锁/对象锁 (syncronized): 响应式调用中难以使用
- 对象锁+缓存: 实现比较复杂
在加锁以后如果发生并发修改的时候，只有第一个写入操作会成功，后续写入都会失败。所以需要为整个游戏操作加入重试机制。此逻辑可以用Reactive的retry机制方便的实现。但重试会带来多次数据库读写增加的问题。如并发数为n，则最高重试次数为(1+n)*n/2(例：12个玩家同时加入游戏，最多可能发生78次加入游戏处理)。
ReactiveMongoRepository的save方法实现自带乐观锁。只要实体定义了带有@Version注解的字段，在调用save时就会自动用version进行乐观锁校验，并在发现版本错误时抛出OptimisticLockingFailureException。同时也会在save时自增version。
无锁方案分析
在Game操作中按照GameId分配线程，同一个GameId的操作都使用同一个线程。
此实现的难点主要在于根据GameId创建线程，以及将MongoDB的读写切换到GameId对应的线程上。
PublisherMapping的问题
我们在PublisherMapping中使用了mutableMapOf()生成了一个用来存储游戏房间广播器(WebSocketPublisher)的map。玩家加入房间时，会调用createPublisherIfNotExist()来创建或获取本房间的广播器。当所有玩家离开房间时，会调用removePublisher()来释放广播器。然而，当玩家并发加入或离开房间时，广播器的管理可能会有问题，因为这两个方法都不是线程安全的。
改造方案：
- (有锁方案)将PublisherMapping中对map进行读写的方法都加上锁-
syncronized(msgPublisherMap) - (无锁方案)将PublisherMapping中对map进行读写的方法改造成支持响应式调用，并限制在固定线程执行。
