异步持久化策略对比

1.背景

游戏服务器其中一项重点工作，就是对游戏玩家的数据进行持久化，保证下次登录可以再续前缘。如果游戏服务器架构里没有缓存，每次操作都需要读写数据库，无疑对数据库带来非常大的压力。一旦使用缓存，就伴随异常持久化的需求。也就是说，玩家数据先写入缓存，然后服务器在稍后的某个时候，再把数据回写到数据库。

这里的“某个时候”，就有几种策略。

排队策略：采用“先进先出”的策略，排在前面的数据先入库，多次操作去重。

延迟策略：先拿个号，XX时间后，再入库，期间的多次操作直接进行数据合并。

定时策略：基于cron表达，例如每隔五分钟，将排队的所有数据批量更新。

2.代码实现

2.1.实体接口

说实在，加这个接口多少带点无奈，因为加了就强迫用户的领域类实现该接口，对用户的现有代码造成了入侵。但是不加这个，又无法解决一个难题。当用户引入了Redis等进程外缓，每次从Redis读取的数据都是重新序列化的。持久化容器没办法判断前后两个对象是不是同一个对象。

所以这个接口的唯一目的，就是提供一个getId()接口，以便容器能够去重。