顺序性保障
连接丢失时的顺序性
zookeeper会取消等待的请求,同步方法会抛出异常,对于异步请求调用,回调函数会返回结果码来标示连接丢失,这种情况下依赖客户端解决后续的操作,而不能依赖zk承担这些操作
考虑连接丢失的影响,考虑以下顺序事件
1应用程序提交请求,执行op1操作
2客户端检测到了连接丢失,取消op1操作请求
3客户端在会话过期前重新连接
4应用程序提交请求,执行op2操作
5op2执行成功
6po1返回connectionloss事件
7应用程序重新提交op1请求
这种情况下op2先与op1成功,如果op1重试,还有失败的可能,不断重试是不行的,所以要设置重试的次数;
如果op2的执行要在op1之后,需要保证执行请求的先后顺序,这种可能会使应用程序性能 下降,程序并不能并行执行
摆脱connectionloss事件会怎么样
在zookeepere设计上,它标示一个连接丢失的事件,重连后,客户端可以重新查询断链之前提交请求的执行情况,可以从服务器缓存中获取执行结果
同步api和多线程执行的问题
多线程中同步调用多个请求,这种情况下,并不能保证顺序性,可能后提交的请求先执行,在有执行顺序的请求中,这种方式并不能直接使用
同步和异步混合调用的形式
异步调用了aop1,aop2,在aop1的异步回调中执行了sop1,如果这个同步调用阻塞了客户端的分发线程,这样线程的执行顺序为aop1,sop1,aop2;
而实际提交的顺序为aop1,aop2,sop1;
数据字典和子节点的限制
zookeeper上限制了可以存储的数据大小和一个父节点下的子节点数,这个值在数据量大的应用中可以修改
应用中嵌入zookeeper服务,将服务的实例化放在应用当中,这样会耦合到一起,使系统复杂化