NIO总结(六)--RPC与zookeeper

RPC包括了:序列化/反序列化,网络通信,反射等等技术。                
序列化和反序列化:                
对象本身是存在内存中的,而对象在内存中存货的状态是无法直接用来保存和传输的,将内存中的对象和从这种状态转换为可以用字节形式表示便于保存或传输的过程。称为将对象序列化。    
将序列化后的对象恢复为内存中的对象的过程叫反序列化。                
序列化:对象->字节                
反序列化:字节->对象                
只有成为字节时才能在网络中传输。                
持久化,反持久化                
对象存在内存时,是易失状态,将读写从这个易失状态转换为持久化设备中不易丢失的状态过程叫持久化。                
将持久化设备中已持久化的对象恢复到内存中的过程叫反持久化。                
持久化的前提是序列化,但是序列化的目的不一定是持久化。                    
InputStream,OutputStream                
Serializable,不需要实现任何方法,是一个标记接口,表示这个类的对象允许被序列化                
序列化:output,对象转字节,反序列化:input,字节转对象                
编译阶段:.java编程.class。                
反序列化首先检查被序列化的字节是否与以前一致。                
序列化和反序列化唯一标识:serialVersionUID                
☆☆当在两台机器上进行序列化反序列化操作时(RPC),只有把serialVersionUID手动改成一致的时候才能实现跨机器的序列化和反序列化。                
关键字:transient,指定序列化时,忽略本字段。                
以上java序列化反序列化缺点:                
1.只支持java语言,无法跨语言                
2.序列化完成后产生的数据量比较大(3个属性的对象就90字节太大)                
3.执行序列化反序列化操作的效率比较低                
所以,现在使用的比较少。                
第三方序列化和反序列化框架:以下三个第三方框架都可以跨语言,且空间占用小。                
1.Avro -- Apache,主讲                
2.Google ProtoBuffer -- Google                
3.Thrift                
此三样没太大区别,理念是一样。                
GoogleProtoBuffer的使用:                
1.写proto文件(参照zebra/Proto相关)->2.编译成类文件->3.导入类文件(在java或者其它语言工具中)进行序列化反序列化                
ProtoBuffer语言指南,Proto文件中的数字是属性独一无二的ID(标识)此标识是标识字段用的,指定完不能修改。1~15标识符占一个字节                
16~2047是占两个字节,最好使用1~15。不可以使用其中的19000-19999标识符,                
protobuf协议实现中对这些进行了预留。                
required是永久性de ,一个格式良好的消息一定要含1个这种字段,表示该值是必须设置的                
optional:消息格式中该字段可以有0个或者1个值(不超过1个)。                
repeated:在一个格式良好的消息中,这种字段可以重复任意多次(含0次)    重复的值的顺序会被保留(相当于java的list)                
一个.proto文件中可以声明多个message(message相当于class),只有一种注释//                
详细参照:Protobuf语言指南 (.cpp是C++)                
执行proto文件,解压完protoc.exe编译器,把.proto文件和.exe放在同一文件夹                
然后打开cmd命令行,进入大.proto和编译器所在文件,输入命令行:                
protoc.exe --proto_path=E:\勉強\开发\大数据相关\zebra\Proto相关 --java_out . person.proto                
如果已进入当前目录下则输入:protoc.exe --java_out . ./Person.proto                
proto在序列化和反序列化时候支持跨语言,支持跨机器(跨IP,跨域)                
RPC(远程方法调用):                
例子:从A机器调B机器方法,从A机器传两个数2,3,B机器做一个加法运算,返回给A机器一个5。                
参照:MathClient.java和MathService.java讲解远程方法调用                
分布式数据一致性问题:                
zooeeper介绍:是一个开方源码的分布式协调服务,是一种典型的分布式数据一致性解决方案,由雅虎创建,贡献给apache。                
利用zookeeper可以实现数据发布订阅,负载均衡,命名服务,分布式协调/通知集群管理分布式锁,分布式队列等功能。协调管理各个大数据软件。    
zookeeper特点:                
1.顺序一致性:从同一个客户端发起的事务请求,最终将会严格按照其发起顺序被应用到zookeeper中。(同一客户端发出的按照顺序执行),靠编号保证》》
2.原子性:(所有机器同时变,要么一起变要么都不变)所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的,即,要么整个集群中所有及其都成功应用了某一个事务,要么都没有应用,一定不会出现集群中部分及其应用了该事务,另外一部分没有应用的情况。靠过半同意原理保证》》                
3.单一视图:无论客户端连接的是哪个zookeeper服务器,其看到的服务端数据模型都是一致的。                
4.可靠性,一旦服务端成功的应用了一个事务,并完成对客户端的相应,那么该事务所引起的服务端状态变更会一直保留下来,除非有另一个事务又对其进行改变。过半同意过半存活保证》》》
5.实时性:zookeeper不是一种一致性,只能保证顺序一致性和最终一致性,只能说达到了伪实时性。(并不能保证时时刻刻都一致)                
分布式数据一致性问题是一个很基础的问题,由zookeeper去解决这个问题。                
以上五个特点是如何保证的呢??                
zookeeper-分布式环境下数据一致性的保证:                
1.客户端发出的每一个命令都要有递增的ID来保证顺序一致性☆。                
2.集群中需要有一个说了算的leader☆:客户端连接zookeeper时,要做增删改的操作,需要找leader,如果直接找到leader则直接操作,如果找到的是非leader则非                
leader将请求转发给leader,leader尽量通知能通知到的所有服务器,尽量接受到其它服务器的返回消息(一定数量是多少:坚持一半以上原则)                
机器数   同意   最多允许挂几台                
2            2           0                
3            2           1                
4            3           1                
5            3           2                
6            4           2                
7            4           3                
8            5           3                
zookeeper中的服务器最好是奇数,因为偶数存在浪费一台的情况。(一半以上原则)一半以上的机器挂了的情况下,整个集群不工作,因为存在的服务器是一半以下了。                
zookeeper工作原理:为了保证可靠性应该是一个集群。                
为了保证zookeeper集群数据能够一致,必须有一个拍板说了算的人,这就是leader,某一时刻集群里智能有且只有一个leader。                
leader可以执行增删改和查询操作,而follower智能进行查询操作。                
所有的更新操作都会被转交给leader来处理,leader批准的任务,再发送给fllower执行来保证执行一致。                
优于网络是不稳定的,为了保证执行顺序一致,所有的任务都会被赋予一个唯一的顺序编号。来保证任务顺序的一致性。                
那么什么时候leader可以认为一个客户端的请求可以算是处理成功了过半同意原则!!!                
所以leader在收到客户端提交过来的任务后,会向集群中所有的follower发送提案等待follower的投票,follower们收到这个提以后,会进行投票,同意或者不同意,leader                
会回收投票,一旦收到过半的投票表示统一,则leader任务这个提案通过,返回给所有follower进行执行这个提案。                
leader选举:                
    最开始集群启动时,会选择最先启动的机器作为leader。            
    (假如5台机器当启到第三台才可以工作集群,所以第三台是leader,即使集群开始工作的那台机器)            
    当leader挂掉后,会通过过半投票选出具有最高任务编号称为新的leader。            
zookeeper的数据模型:                
采用了共享的,树型结构的名字空间来进行互相协调。                
类似一个文件系统,zookeeper中的数据模型由一系列的被称为ZNode的数据节点保持层级关系来组成,通过这种层级关系,及在层级关系中保存数据来工作。
由整个ZNode树维系在内存中,所以可以实现高吞吐,低延迟的访问效果。            
zookeeper通常采用集群模式,由多台机器组成,保证zookeeper本身的高可用性,根据其采用的zab算法,    集群中只要超过半数的机器存货,集群即可继续工作。                
文件系统由文件和文件夹组成的一个树。zookeeper也是类似于文件系统的存在,它是由znode组成。                
它跟文件系统不一致的是,znode里包含znode,znode可以直接保存数据,而且znode保存在内存中,效率极高。                
高可用:集群由多台机器组成,死了一部分还可以使用(一半以上原则:集群一半以上存活即可用)。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

戰士

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值