很多服务器，怎么保持数据的实时同步呢？

很好的问题，我说下我的想法，
腾讯有很多服务器，北京上海应该不是登录同一个服务器，但是数据库应该是同一个，用户资料这种数据应该也是采取分布式存储的（不一定是放在关系型数据库里面，腾讯这种公司现在在很好的使用云技术），有一个核心主库，各分布式服务器上的数据作为主库的实例缓存在分布式环境中，而修改在线签名这种 *** 作，技术上认为是需要及时同步到主库的，那么上海服务器需要什么资料时，肯定需要从主库拿一次的，这时候拿到的肯定是最新的，同时主库发生了什么变更的时候可以主动发起一个PUSH *** 作，同步各分布式实例。总之，分布式环境下，我们可以定义同步 *** 作的重要级别，级别高的需要迅速完成同步的，并不一定很多，所以效率上面没有问题就可以了。

打开“360安全浏览器”，点击窗口左上角的“LOGO”图标，然后在d出的窗口中输入账号和密码进行登陆。
接着点击浏览器窗口左上角的“头像”，从d出的窗口中点击开启“我的收藏夹 备份开启”。以后就可以通过“收藏夹”菜单项向其中添加网页链接啦。转到要收藏的页面，点击“收藏夹”→“添加到收藏夹”项。在d出的“添加到收藏夹”窗口中，将“创建位置”设置为“网络收藏夹”，最后点击“添加”按钮即可。以后在其它电脑上进行浏览网页时，如果想使用自己的收藏夹中的内容，只需要打开360安全浏览器，用自己的360账户和密码进行登陆，就可以正常使用网页收藏夹啦。

不管是否是微服务架构，应用的各个模块之间都需要频繁的通信、协作、共享数据，实现系统的整体价值。区别点在于单体应用是通过本地方法调用来完成；在微服务中是通过远程API调用完成。
而共享数据最贱的方式就是采用共享数据库模式，也就是单体应用中最常用的方式，一般只有一个数据库，如图一库多服和一库一服的方式:
一库多服的架构模式通常会被认为是微服务架构下的反范式，它的问题在于：
稳定性：单点故障，一个数据库挂掉，整批服务全部停止。服务独立性被扼杀？
耦合性：数据在一起，会给贪图方便的开发或者DBA工程师编写很多数据间高度依赖的程序或者工具；
扩展性：无法针对某一个服务进行精准优化或扩展，服务会大体分为两个读多写少、写多读少，数据库优化是根据服务而来的，不是一篇而论。
所以随行付内部一般推荐的做法：是为每一个微服务准备一个单独的数据库，即一库一服模式。这种模式更加适合微服务架构，它满足每一个服务是独立开发、独立部署、独立扩展的特性。当需要对一个服务进行升级或者数据架构改动的时候，无须影响到其他的服务。需要对某个服务进行扩展的时候，也可以手术式的对某一个服务进行局部扩容。
那么问题来了，在改造中我们发现，以下问题，诞生了该项目：
报表中心和前端详细页都存在SQL Join方式，经历我们一库一服的拆分后，无法在继续使用SQL Join方式了
数据中心，做得是数据聚合，数据拆分后，给数据中心带来了很大的麻烦
微服务之后，各个应用模块对数据库的要求出现了分歧，数据库类型多元化自主选择还是统一
等等

---