hazelcast客户端连接和操作代码逻辑分析
2014-03-18 17:40
274 查看
1.下面以一个客户端创建和发请求的过程来分解描述。
2.故障转移:
首先当ClientClusterServiceImpl启动之后就产生一个一直监听节点存活情况的线程[cluster-listener]。
那么假设在执行mapCustomers.put(1, "Joe");操作前,其要操作的实际节点挂了,这时[cluster-listener]线程会立即感知并更新虚拟节点表。如果在更新完毕后操作才发出请求,则操作可以成功,如果在更新未完成时发出了请求,则会抛出异常。而这个更新虚拟节点表的过程需要几秒钟。在这几秒钟里对失效节点的操作就真的失败了。、
3.数据一致性:
客户端向 Hazelcast写入数据本体所在节点是必须同步的;而备份过程默认是同步的,也可以修改配置成异步。为了保证一致性,默认情况下,读取数据总是从数据的owner节点读取,这个也可以修改配置成允许从备份节点读数据,这样能给你带来更好的读性能。
举例来说,要更新key为1的数据时,由一致性hash算法得知其存在节点A上,则对节点A发起update请求,这时如果你用另一个客户端也要更新节点A上的key1时,咱俩这个操作肯定是同步控制的。而节点A把key1备份到节点B的过程你可以配成同步,然后再配成允许从备份节点读取,这样保证了一致性和高可读。如果备份过程配成异步,再配成不允许从备份节点读取,则保证了高可写,而一致性也基本ok,只是万一异步备份未完成时,数据本体所在节点挂掉,那数据就可能脏了。
public static void main(String[] args) { ClientConfig clientConfig = new ClientConfig(); clientConfig.addAddress("10.10.4.40:5701"); // client初始化时会创建一系列service(线程池管理器、集群客户端服务、虚拟节点管理、动态扩展服务等),先启动ClientClusterServiceImpl,读取当前活动的实际节点(先根据clientConfig指定的地址获取connection,然后基于这个连接,再发起读取实际节点的请求),然后启动ClientPartitionServiceImpl,向各个实际活动节点发起请求获取其上的虚拟节点,记录到一个ConcurrentHashMap里。 HazelcastInstance instance = HazelcastClient.newHazelcastClient(clientConfig); // 这里的map并不是真的map,而是一个mapProxy // 并且这里要指定key和value的类型 Map<Integer, String> mapCustomers = instance.getMap("customers"); // put时,由这个mapProxy先把key和value都序列化为byte[] // 然后用key的hash对虚拟节点数取余:key.getHash()%271,获得partitionId // 根据ClientPartitionServiceImpl里的ConcurrentHashMap记录的虚拟节点和实际节点的对应关系,确定了该key对应的实际节点。然后通过BufferedOutputStream方式 对该地址发起操作请求。 mapCustomers.put(1, "Joe"); // 跟put类似,定位节点,然后发请求。只是请求类型不同而已。 System.out.println("Customer with key 1: "+ mapCustomers.get(1)); System.out.println("Map Size:" + mapCustomers.size()); }
2.故障转移:
首先当ClientClusterServiceImpl启动之后就产生一个一直监听节点存活情况的线程[cluster-listener]。
那么假设在执行mapCustomers.put(1, "Joe");操作前,其要操作的实际节点挂了,这时[cluster-listener]线程会立即感知并更新虚拟节点表。如果在更新完毕后操作才发出请求,则操作可以成功,如果在更新未完成时发出了请求,则会抛出异常。而这个更新虚拟节点表的过程需要几秒钟。在这几秒钟里对失效节点的操作就真的失败了。、
3.数据一致性:
客户端向 Hazelcast写入数据本体所在节点是必须同步的;而备份过程默认是同步的,也可以修改配置成异步。为了保证一致性,默认情况下,读取数据总是从数据的owner节点读取,这个也可以修改配置成允许从备份节点读数据,这样能给你带来更好的读性能。
举例来说,要更新key为1的数据时,由一致性hash算法得知其存在节点A上,则对节点A发起update请求,这时如果你用另一个客户端也要更新节点A上的key1时,咱俩这个操作肯定是同步控制的。而节点A把key1备份到节点B的过程你可以配成同步,然后再配成允许从备份节点读取,这样保证了一致性和高可读。如果备份过程配成异步,再配成不允许从备份节点读取,则保证了高可写,而一致性也基本ok,只是万一异步备份未完成时,数据本体所在节点挂掉,那数据就可能脏了。
相关文章推荐
- srs 服务器在客户端断开连接后,服务器代码跟踪分析
- 客户端连接不上Azure和腾讯云服务器里跑的代码
- Java连接MySQL数据库及简单操作代码
- JD-GUI反编译后代码逻辑分析
- android ril 代码逻辑分析
- ECClient 红孩子android客户端listview图片加载(优化)核心代码分析
- xfire 客户端代码分析
- JDBC连接Oracle代码案列操作之--Oracle简单数据准备
- 阿里AndFix热修复代码逻辑分析
- 通过python代码远程连接服务器进行操作之paramiko模块
- [VB.NET]点net写client程序传递参数给mssql存储过程insert,为什么要反复执行客户端代码才能成功insert,怎么才能使客户端插入记录操作变得稳定呢?
- 支持阻塞操作和轮询操作的globalfifo设备驱动代码分析以及测试代码
- 区块链教程Fabric1.0源代码分析Peer Deliver客户端
- php中mysql连接和基本操作代码(快速测试使用,简单方便)
- Openfire + ConnectionManager 连接正常但客户端操作失败
- CAS单点登录原理,CAS服务端和客户端验证流程,抓包分析,CAS代码分析
- Spark SQL模块代码分析(查询语句到逻辑查询计划树的过程)
- 路由器连接校园网并发WIFI:WR703N路由器安装OpenWRT并运行H3C客户端操作步骤(主要针对中山大学东校区)
- jQuery选择器代码详解(六)——Sizzle选择器匹配逻辑分析
- unix网络编程的5.12代码,当客户端试图连接时,出现溢出