这样的后端架构适合做读写分离吗？

[olist]

数据层只有一个 mysql 。玩家登录时，后端会加载和玩家相关的绝大部分数据并缓存在服务端。小部分数据根据客户端请求实时查询数据库后返回。数据变化时，先修改服务端的数据，然后更新到数据库。
上面提到的”绝大部分数据“是不是不适合做读写分离？因为主从复制的延迟会导致登陆时读到脏数据，并在此基础上修改并同步到主库。实时同步又会影响性能。分表分库或加 redis 缓存应该更适合，但这些改动大，自己没有什么信心。
大家有什么建议吗？

[CEBBCAT]

可以讲讲为什么数据更新时先修改服务端数据再更新到数据库吗？一般的做法不都是先确保数据持久化了，然后再解决数据一致性吗？

听起来就好像是从河流的下游取一瓢水，去推断上游一样，而且还把这瓢水放回上游去了

[CEBBCAT]

信息的流动是有方向的，之前还能说数据是单向流动的（如果你是单机的话），那现在的这个方案就是黄河大合唱，信息的流动方向是混乱的

[index90]

write through 缓存？（先修改服务端数据，然后更新数据库）
你应该做到了玩家同一时间只会出现在一个服务节点上吧？这样还需要担心脏数据吗？

[olist]

@CEBBCAT 因为现在玩家的数据只会由一台服务器修改，所以可以这样处理。至于为什么这么设计，我也说不清，因为是其他人设计的。

[olist]

@index90 现在是没有脏数据的问题，但打算做读写分离，这个可能导致读到的数据不是最新的。

[leafre]

缓存就是读写分离