时间戳服务器id是什么

A. IP和ID有什么不同

1 本身代表含义不同：

ID是IDentity的缩写，身份标识号码的意思。

IP是Internet Protocol的缩写，中文简称为“源雀网协”，也就是为计算机网络相互连接进行通信而设计的协议。

2 作用不同：

IP是网络内参数，起到连接的作用；

ID是账户身份，起到联系、验证的作用。

3 网络中扮演角色不同：

IP是你的唯一上网地址，也就是你上网的唯一凭证，相当于你的家庭住址；

ID是你在某个网站申请的用户名，可以有多个，并且ID在你申请的网站外是没有用的。

(1)时间戳服务器id是什么扩展阅读：

IP地址：

所谓IP地址就是给每个连接在互联网上的主机分配的一个32位地址。

IP地址就好像电话号码（地址码）：有了某人的电话号码，你就能与他通话了。同样，有了某台主机的IP地址，你就能与这台主机通信了。

按照TCP/IP（Transport Control Protocol/Internet Protocol，传输控制协议/Internet协议）协议规定，IP地址用二进制来表示，每个IP地址长32bit，比特换算成字节，就是4个字节。

例如一个采用二进制形式的IP地址是一串很长的数字，人们处理起来也太费劲了。为了方便人们的使用，IP地址经常被写缓裂竖成十进制的形式，中间使用符号“.”分开不同的字节。

于是，上面的IP地址可以表示为“10.0.0.1”。IP地址的这种表示法叫做“点分十进制表示法”，这显然比1和0容易记忆得多。

有人会以为，一台计算机只能有一个IP地址，这种观点是错误的。我们可以指定一台计算机具有多个IP地址，因此在访问互联网时，不要以为一个IP地址就是一台计算机；

另外，通过特定的技术，也可以使多台服务器共用一个IP地址，这些服务器在用户看起来就像一台主机似的。

将IP地址分成了网络号和主机号两部分，扰大设计者就必须决定每部分包含多少位。网络号的位数直接决定了可以分配的网络数（计算方法2^网络号位数）；

主机号的位数则决定了网络中最大的主机数（计算方法2^主机号位数-2）。然而，由于整个互联网所包含的网络规模可能比较大，也可能比较小，设计者最后聪明的选择了一种灵活的方案：

将IP地址空间划分成不同的类别，每一类具有不同的网络号位数和主机号位数。

IP地址是IP网络中数据传输的依据，它标识了IP网络中的一个连接，一台主机可以有多个IP地址。IP分组中的IP地址在网络传输中是保持不变的。

IP （网络之间互连的协议）-网络

B. 如何产生唯一的server id

我们都知道Mysql用server-id来唯一的标识某个数据库实例，并在链式或双主复制结构中用它来避免sql语句的无限循环。这篇文章分享下我对server-id的理解，然后比较和权衡生成唯一server-id的几种方式。
server_id的用途
简单说来，server_id有两个用途：
1. 用来标记binlog event的源产地，就是SQL语句最开始源自于哪里。
2. 用于IO_thread对主库binlog的过滤。如果没有设置 replicate-same-server-id=1 ，那么当从库的io_thread发现event的源与自己的server-id相同时，就会跳过该event，不把该event写入到relay log中。从库的sql_thread自然就不会执行该event。这在链式或双主结构中可以避免sql语句的无限循环。
注意：相同server-id的event在io_thread这一层就过滤了；而对于replicate-(do|ignore)-等规则，则是在sql_thread这一层过滤的。io_thread和sql_thread都有过滤的功能。
server_id为何不能重复
在同一个集群中，server-id一旦重复，可能引发一些诡异问题。
看看下面两种情况：
图1：主库与从库的server-id不同，但是两个或多个从库的server-id相同
这种情况下复制会左右摇摆。当两个从库的server-id相同时，如果从库1已经连接上主库，此时从库2也需要连接到主库，发现之前有server-id相同的连接，就会先注销该连接，然后重新注册。
参考下面的代码片段：
repl_failsafe (register_slave) download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
int register_slave(THD* thd, uchar* packet, uint packet_length)
{
int res;
SLAVE_INFO *si;
...
if (!(si->master_id= uint4korr(p)))
si->master_id= server_id;
si->thd= thd;
pthread_mutex_lock(&LOCK_slave_list);
/* 先注销相同server-id的连接*/
unregister_slave(thd,0,0);
/* 重新注册*/
res= my_hash_insert(&slave_list, (uchar*) si);
pthread_mutex_unlock(&LOCK_slave_list);
return res;
...
}

两台从库不停的注册，不停的注销，会产生很多relay log文件，查看从库状态会看到relay log文件名不停改变，从库的复制状态一会是yes一会是正在连接中。
图2：链式或双主结构中，主库与从库的server-id相同
从库1同时又是relay数据库，它能正确同步，然后把relay-log内容重写到自己的binlog中。当server-id为100的从库2 io线程获取binlog时，发现所有内容都是源自于自己，就会丢弃这些event。因此从库2无法正确同步主库的数据。只有直接写relay server的event能正确同步到从库2。
上面两种情况可以看到，在同一个replication set中，保持server-id的唯一性非常重要。
server_id的动态修改
无意中发现 server-id 竟然是可以动态修改的，可别高兴的太早。好处是，上面图1的情况下，直接修改其中一个从库的server-id就可以解决server-id冲突的问题。坏处很隐蔽，如下图的结构：

现在假设active-master因为某种原因与passive-master的同步断开后，passive-master上进行了一些ddl变更。然后某dba突发奇想把passive-master的server-id修改为400。当双master的复制启动后，那些之前在passive-master上执行的server-id为200的ddl变更，会从此陷入死循环。如果是 alter table t engine=innodb ，它会一直不停，可能你会发现。但是像 update a=a+1； 这样的sql，你很难发现。当然这种场景只是我的杜撰，这儿有个更真实的例子 主备备的两个备机转为双master时出现的诡异slave lag问题 。
举这两个例子只是想说明修改server-id有点危险，最好不要去修改，那么能一步到位生成它吗？
如何生成唯一的server_id
常用的方法有如下几种：
1. 采用随机数
mysql的server-id是4字节整数，范围从0-4294967295，因此采用该范围内的随机数来作为server-id产生冲突的可能性是非常小的。
2. 采用时间戳
直接用date +%s来生成server-id。一天86400秒来计算，往后计算50年，最大的server-id也才使用到86400*365*50，完全在server-id范围内。
3. 采用ip地址+端口
这是我们经常采用的方法。例如ip为192.168.122.23，端口为3309，那么server-id可以写为122233309。产生冲突的可能性比较小：遇到*.*.122.23 或者*.*.12.223，而且搭建了同一个replication set的3309才会出现。
4. 采用集中的发号器
在管理服务器上采用自增的id来统一分配server-id。这可以保证不冲突，但是需要维护中心节点。
5. 分开管理每个replication set
在每个replication set中为mysql库增加一个管理表，保证每个从库的server-id不冲突。
哪一种更好
上面的几种方法都不赖，但是：
1. 方法4加了维护负担，而且开发环境、测试环境、线上环境都维护一套发号器的话，有点麻烦，混在一起又可能遇到网段隔离的风险，还有发号器数据库权限的问题难于控制。所以不推荐。
2. 方法5实现了自治，但是管理成本有点高。从库要能够写主库的server-id表，复杂。
3. 5种方法都存在的问题是，使用冷备的数据来扩容，server-id需要手动去修改，否则就与冷备源的server-id冲突。而且，当mysql启动的时候，你无法判断该mysql是刚通过备份扩容的，还是之前一直正常运行的。所以你不知道这个server-id到底要不要改。而我希望server-id对dba完全透明，又绝不产生冲突，即可彻底屏蔽这个讨厌的东西。
建议的方法
其实很简单。ipv4是4字节的整数，与server-id的范围完全一样。我们认为只有ip地址+端口才能唯一的确定一个mysql实例，所以总是希望把ip信息和端口信息都集成到server-id中。但是别忘了，一个ip上不能同时启动两个一样的端口。所以，server-id只需采用ip地址的整数形式！自定义的mysql启动脚本强制对server-id进行检查，发现server-id不对就进行纠正，然后启动。上面所有的问题，都会迎刃而解。

C. bbo和zookeeper

bbo 是一个远程调用服务的分布式框架，可以实现远程通讯、动态配置、地址路由等等功能。比如在入门demo里的暴露服务，使得远程调用的协议可以使用dobbo协议( bbo://x.x.x.x )或者其它协议，可以配置zookeeper集群地址，实现软负载均衡并配置均衡方式等。在不搭配注册中心的时候，它也是可以实现服务端和调用端的通信的，这种方式是点对点通信的，所谓“没有中间商”。但是如果配置服务发布和调用端过多特别是集群的方式提供服务的时候，就会暴露许多的问题：增加节点需要修改配置文件、服务端机器宕机后不能被感知等。它可以通过集成注册中心，来动态地治理服务发布和服务调用。相当于把服务注册和发布推送的功能分摊给了(zookeeper)注册中心。

Dubbo实现服务调用是通过RPC的方式，即客户端和服务端共用一个接口(将接口打成一个jar包，在客户端和服务端引入这个jar包)，客户端面向接口写调用，服务端面向接口写实现，中间的网络通信交给框架去实现。

咱们来看下Spring 配置声明暴露服务，provider.xml文件

再来看服务消费者，consumer.xml文件

这就是典型的点对点的服务调用。当然我们为了高可用，可以在consumer.xml中配置多个服务提供者，并配置响应的负载均衡策略。

配置多个服务调用者在comsumer.xml的bbo:reference标签的url属性中加入多个地址，中间用分号隔开即可；配置负载均衡策略在comsumer.xml的bbo:reference标签中增加loadbalance属性即可，值可以为如下四种类型：

那么目前的架构有什么问题呢？
1.当服务提供者增加节点时，需要修改配置文件。
2.当其中一个服务提供者宕机时，服务消费者不能及时感知到，还会往宕机的服务发送请求。

这个时候就需要引入注册中心了，Dubbo目前支持4种注册中心(multicast、zookeeper、redis、simple)推荐使用Zookeeper注册中心，要使用注册中心，只需要将provider.xml和consumer.xml更改为如下：

如果zookeeper是一个集群，则多个地址之间用逗号分隔即可

把consumer.xml中配置的直连的方式去掉

注册信息在zookeeper中如何保存？
启动上面服务后，我们观察zookeeper的根节点多了一个bbo节点及其他，图示如下

最后一个节点中服务的地址，为什么把最后一个节点标成绿色？因为最后一个节点是临时节点，而其他节点是持久节点，这样，当服务宕机时，这个节点就会自动消失，不再提供服务，服务消费者也不会再请求。如果部署多个DemoService，则providers下面会有好几个节点，一个节点保存一个DemoService的服务地址。
其实一个zookeeper集群能被多个应用公用，因为不同的框架会在zookeeper上建不同的节点，互不影响。如bbo会创建一个/bbo节点，storm会创建一个/storm节点。

zookeeper 介绍：
zookeeper是 Apacahe Hadoop 的子项目，是一个树型的目录服务，支持变更推送，适合作为 Dubbo 服务的注册中心，工业强度较高，可用于生产环境，并推荐使用。

流程说明：

支持以下功能：

补充：
bbo的协议使用什么序列化框架？
bbo有多种协议，不同的协议默认使用不同的序列化框架。比如bbo协议默认使用 Hessian2 序列化(说明：Hessian2 是阿里在 Hessian 基础上进行的二次开发，起名为Hessian2)。rmi协议默认为 java 原生序列化，http协议默认为为 json。

bbo的通信方式？
采用单一长连接和NIO异步通信，基于Hessian2作为序列化协议。适合于小数据量（每次请求在100kb以内）大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况。具体实现是消费者使用 NettyClient，提供者使用 NettyServer，Provider 启动的时候，会开启端口监听，使用我们平时启动 Netty 一样的方式。而 Client 在 Spring getBean 的时候，会创建 Client，调用远程方法的时候，将数据通过DubboCodec编码发送到 NettyServer，然后 NettServer 收到数据后解码，并调用本地方法，并返回数据，完成一次完美的 RPC 调用。

zookeeper选举机制？
zookeeper选举算法默认的是FastLeaderElection，选举机制的概念：
1.服务器ID：比如有三台服务器，编号分别是1、2、3，编号越大在选择算法中的权重越大。
2.事务ID：服务器中存放的最大数据ID(致使ZooKeeper节点状态改变的每一个操作都将更新事务id，即时间戳)，值越大说明数据越新，在选举算法中数据越新权重越大。
3.逻辑时钟，或者叫投票的次数，同一轮投票过程中的逻辑时钟值是相同的。每投完一次票这个数据就会增加，然后与接收到的其它服务器返回的投票信息中的数值相比，根据不同的值做出不同的判断。
选举状态：LOOKING：竞选状态；FOLLOWING：随从状态，同步leader状态，参与投票；OBSERVING：观察状态,同步leader状态，不参与投票；LEADING：领导者状态。
初次选举简述：
目前有5台服务器，每台服务器均没有数据，它们的编号分别是1,2,3,4,5,按编号依次启动，它们的选择举过程如下：
1.服务器1启动，给自己投票，然后发投票信息，由于其它机器还没有启动所以它收不到反馈信息，服务器1的状态一直属于Looking。
2.服务器2启动，给自己投票，同时与之前启动的服务器1交换结果，由于服务器2的编号大所以服务器2胜出，但此时投票数没有大于半数，所以两个服务器的状态依然是LOOKING。
3.服务器3启动，给自己投票，同时与之前启动的服务器1,2交换信息，由于服务器3的编号最大所以服务器3胜出，此时投票数为3正好大于半数，所以服务器3成为领导者，服务器1,2成为小弟。
4.服务器4启动，给自己投票，同时与之前启动的服务器1,2,3交换信息，尽管服务器4的编号大，但之前服务器3已经胜出，所以服务器4只能成为小弟。
5.服务器5启动，后面的逻辑同服务器4成为小弟。
如果中间有节点挂掉，只要有半数以上节点存活，就可以正常服务，如果leader挂掉，则所有节点处于Looking状态 ，各自依次发起投票，投票包含自己的服务器ID和最新事务ID，如果发现别人的事务id比自己大，也就是数据比自己新，那么就重新发起投票，投票给目前已知最大的事务id所属节点(事务id一样，则数据id大的胜出)。每次投票后，服务器都会统计投票数量，判断是否有某个节点得到半数以上的投票。如果存在这样的节点，该节点将会成为准Leader，状态变为Leading。其他节点的状态变为Following。

引用：
https://www.cnblogs.com/iisme/p/10620125.html