step 1 - 启动时
Eureka Server也是一个Client，在启动时，通过请求其中一个节点（Server），将自身注册到Server上，并获取注册服务信息；
Step 2 - 信息变更时
每当Eureka Server信息变更后（client发起注册，续约，注销请求时），就将信息通知给其他Server，来保持数据同步；
Step 3 - 解决Eureka Server之间的数据同步死循环
如果自己的信息变更是另一个Eureka Server同步过来的，这是再同步回去的话就出现数据同步死循环了。
Eureka Server 在执行复制操作的时候，使用 HEADER_REPLICATION 这个 http header 来区分普通应用实例的正常请求，说明这是一个复制请求，
这样其他 peer 节点收到请求时，就不会再对其进行复制操作，从而避免死循环。
Step 4 - 解决数据冲突
还有一个问题，就是数据冲突，比如 server A 向 server B 发起同步请求，如果 A 的数据比 B 的还旧，B 不可能接受 A 的数据，那么 B 是如何知道 A 的数据是旧的呢？这时 A 又应该怎么办呢？
数据的新旧一般是通过版本号来定义的，Eureka 是通过 lastDirtyTimestamp 这个类似版本号的属性来实现的。
lastDirtyTimestamp 是注册中心里面服务实例的一个属性，表示此服务实例最近一次变更时间。
比如 Eureka Server A 向 Eureka Server B 复制数据（把A的数据同步到B），数据冲突有2种情况：
（1）A 的数据比 B 的新，B 返回 404，A 重新把这个应用实例注册到 B。
（2）A 的数据比 B 的旧，B 返回 409，要求 A 同步 B 的数据。