首先务必牢记：若非绝对必要，尽量避免将数据保存多份。只要数据存在不止一个地方，就难免出现数据不一致。通过后文会提到的更合理的同步方式，以及提高编程质量等方式可以减少数据不一致的数量，但仍然很难完全避免。所以应该回到问题的源头，首先问自己几个问题：子系统间保存多份数据是否绝对必要呢？是否能够通过提供操作接口的方式来避免提供数据同步接口？这其实有点类似面向对象中对数据进行封装的思想。举个例子：假设有一个子系统是用来管理用户账户的。这个子系统以其提供获取所有账户密码这样的接口让其他子系统调用（然后其他子系统自行检验用户登录的密码是否正确），不如提供验证用户密码的接口让其他子系统来调用。很多数据同步需求的设计初衷是由于担心某个子系统的性能问题，这种情况下其实应该优先考虑优化子系统的性能（如引入数据库缓存等等）。

    如果经过评估真的有必要进行数据同步的话，接下来要考虑数据同步的两种方式：推送和拉取。推送是数据源子系统主动推送变化的数据到其他子系统（例子：账号子系统通知OA子系统增加一个账号）；拉取是其他子系统来向数据源子系统请求获取数据（例子：OA子系统定时向账号子系统获取所有账号）。总结如下：

    1、用拉取来保证正确性。可以不支持推送，但一定不能不支持拉取。单纯依赖推送机制的话，非常容易产生数据不一致的问题。拉取的频率是一个需要权衡的参数：如果频繁拉取，对系统的压力较大；如果拉取的周期较长，则数据修改的生效时间会比较长。另外数据量较大的情况下，需要设计一定的机制来支持分页拉取。

    2、用推送来保证实时性。如果需要修改立刻在其他子系统生效，则需要依赖推送机制。推送失败的时候应该有重试机制（例子：重试两次，每次间隔1分钟），但不能保证一定推送成功，因为其他子系统不一定在可控范围内（可能是其他部门甚至其他公司的产品）。所以如果只提供推送方式的话，很容易产生数据不一致问题。

     3、结合使用拉取和推送两种方式，可以既保证数据修改的实时性，又保证数据的最终一致。在推送失败后，其他子系统可以自动通过拉取的数据进行修复。这种方式可以避免90%以上的维护问题。是我比较推荐的数据同步方式。