现在游戏后端是怎么做存储的？

宕机=回档+发玩家补尝邮件

宕机无解. 回档是必然

双写备份

https://github.com/viabtc/viabtc_exchange_server
比特币交易所引擎，可以作为参考。

@feelapi 用这个方案估计大家都不能愉快滴玩游戏了。。。

可靠性越高，系统复杂度就越高，可用性也就越低。游戏嘛，还是回档+补偿就完了，最简单。研发满意、策划满意、运营满意、玩家满意，你还有啥不满意的？

游戏我的理解确实都是在内存中操作的。
有没有这种玩法：操作日志可以写 kafka，通过 kafka 同步数据到数据库，比定时同步数据要准确点吧。
如果写 kafka 也影响延迟，可以异步写。

@ZSeptember 我们做的是分区分服的架构，定时同步主要是为了减少 db 的压力，所以你写到 kafka 里然后在写到 db，最终的压力都 db 上，没有必要

又要快，又要好，世间事无两全。

哈哈 是这样
@xuanbg

C++ 的服务端吗？说个非 C++ 的方式，填业务逻辑的地方是框架预留的地方，都做了异常的检测。服务挂掉的时候框架会提供指定的异常回调处理。一般情况下在这里记录日志加回写数据。半年的研发周期本身就应该让宕机的概率变的很低。挂掉还有机会回写将数据丢失的可能性进一步降低（当然，要保证回调里面不再或几乎不会出现异常）。
但是，这样还是不能解决数据一致性问题，比如修改数据一半挂掉。这种情况下回写的数据是不完整的。这种只能通过业务逻辑中的日志来记录。非极端情况下是能将玩家数据恢复到之前一致的。
以前特别纠结这种问题，总想为什么没有既能完全保证数据一致性，性能又好，心智包袱又小的方案，让写业务逻辑的时候无脑一点。现在想想真的太难，老老实实做好日志记录，关键数据一致性问题能通过日志追踪复原到比较理想的状态也差不多了。

就是 mysql 这种，ACID 不开串行异常级别，一致性也不能支撑完全的无脑的开发。
比如扣减余额，转账这种。默认可重复读级别并不能解决并发的问题。只要允许 2 个事务一起操作该数据，一样余额能成负。最终还是需要额外处理。

独立 db server，介于游戏进程和数据库之间