flyingzc's blog

SPI 机制SPI 作用SPI 全称为 Service Provider Interface, 是一种服务发现机制. SPI 的本质是将接口实现类的全限定名配置在文件中, 并由服务加载器读取配置文件, 加载实现类. 这样可以在运行时, 动态为接口替换实现类. 正因此特性, 我们可以很容易的通过 SPI 机制为我们的程序提供拓展功能. Dubbo 里面有很多个组件, 每个组件在框架中都是以接口的形式抽象出来. 具体的实现又分很多种, 在程序执行时根据用户的配置来按需取接口的实现类. Dubbo 实现的 SPI 与 JDK 自带的 SPI 的区别摘自官网 JDK 标准的 SPI 会一次性实例化扩展点所有实现, 如果有扩展实现初始化很耗时, 但如果没用上也加载, 会很浪费资源. 如果扩展点加载失败, 连扩展点的名称都拿不到了.比如: JDK 标准的 ScriptEngine, 通过 getName() 获取脚本类型的名称, 但如果 RubyScriptEngine 因为所依赖的 jruby.jar 不存在, 导致 RubyScriptEngine 类加载失败,...

整理自官网, 对整体理解 Dubbo 很有作用. 作用Apache Dubbo 是一款高性能, 轻量级的 Java RPC 框架. 三大核心能力面向接口的远程方法调用 智能容错和负载均衡 以及服务自动注册和发现 健壮性监控中心宕掉不影响使用, 只是丢失部分采样数据. 数据库宕掉后, 注册中心仍能通过缓存提供服务列表查询, 但不能注册新服务. 注册中心对等集群, 任意一台宕掉后, 将自动切换到另一台. 注册中心全部宕掉后, 服务提供者 和 服务消费者 仍能通过本地缓存通讯. 服务提供者无状态, 任意一台宕掉后, 不影响使用. 服务提供者全部宕掉后, 服务消费者应用将无法使用, 并 无限次重连等待服务提供者恢复. 伸缩性注册中心为对等集群, 可动态增加机器部署实例, 所有客户端将自动发现新的注册中心. 服务提供者无状态, 可动态增加机器部署实例, 注册中心将推送新的服务提供者信息给消费者. 协议 Dubbo 协议采用 NIO 复用单一长连接, 并使用线程池并发处理请求, 减少握手和加大并发效率, 性能较好(推荐使用)在大文件传输时, 单一连接会成为瓶颈可用于生产环境 Rmi...

git 配置 shadowsocks有时候从github里clone代码速度很慢,尤其是项目很大的时候,配置代理会快很多.git config –global http.postBuffer 524288000 git config –global http.proxy socks5://127.0.0.1:10800其中10800为 shadowsocks 服务器->编辑服务器 中配置的代理端口 git取消代理git config –global –unset http.proxy

ZKDataBase结构ZKDataBase(zk内存数据库) – sessionWithTimeouts(zk所有会话 会话超时时间记录器) – DataTree存储 – 事务日志 ZKDatabase会定时向磁盘dump快照数据,在zk启动时通过磁盘上的事务日志 和 快照文件 恢复 一个完整的内存数据库 事务日志dataLogDir 文件大小都是64MB 文件名 log.xxxxxx为事务id : zxid, 且 为写入该事务文件第一条事务记录的zxid. zxid由两部分组成: 高32位 为 当前leader周期(epoch), 低32位 为 真正的操作序列号. LogFormatter 可以查看该文件 事务日志操作 滚动日志FileTxnLog.rollLog()将当前日志文件 滚动为新文件.其实就是将 logStream置为null,那么要写入日志时就会新创建一个日志文件用于写入. 写事务日志FileTxnLog.append(TxnHeader hdr, Record txn) 若logStream == null,...

dubbo中zk的应用123456789在zk中创建的节点路径dubbo com.alibaba.demo.DemoService [服务名,service] configurators consumers [类型,type,生产者消费者] ... providers ... [url] routers 其中接口(service)下会有四个子节点providers, consumers, routers, configurators 其中dubbo、接口、providers都是持久化节点，只有url是临时节点。当会话消失(服务器断开与zookeeper的连接)，对应的临时节点会被删除。 dubbo-registry-zookeeper模块中, ZookeeperRegistry 类继承自 FailbackRegistry.构造方法中通过...

processors PrepRequestProcessor通常是请求处理链的第一个处理器.识别客户端请求是否是事务请求.对于事务请求,做预处理,诸如 创建请求事务头,事务体,会话检查,ACL检查 和 版本检查 等. ProposalRequestProcessorleader 服务器的事务投票处理器,也是 leader 服务器事务处理流程的发起者.对于 非事务请求,它会直接将请求流转到 CommitProcessor 处理器,不再做其他处理.对于 事务请求,除了将请求交给CommitProcessor处理器外,还会根据请求类型创建对应的 Proposal 提议,并 发给所有 Follower 来发起一次集群内的事务投票.它还会将事务请求交给 SyncRequestProcessor 进行事务日志的记录. SyncRequestProcessor事务日志记录处理器,将事务请求记录到事务日志文件中,同时还会触发zk进行数据快照.发送Sync请求的处理器.将请求记录到磁盘.它批量处理有效执行io的请求.在将日志同步到磁盘之前,请求不会传递到下一个...

leader选举相关线程QuorumCnxManager : 管理者,包含发送 和 接收 队列.持有 listener. QuorumCnxManager.Listener : 监听 并 建立 server 之间的连接. FastLeaderElection.Messenger.SendWorker消息生产者.循环 从发送队列 queueSendMap 中取消息(出队)并发送出去.并将该消息存入 lastMessageSent 中. FastLeaderElection.Messenger.RecvWorker消息消费者.循环 接收线程从底层 Socket 收到报文后放到 recvQueue 队列中,等待 Messenger 调用 pollRecvQueue 方法获取消息. leader选举流程启动时选举选举算法的创建之前先创建 QuorumCnxManager,它通过 TCP 协议来进行 leader...

zk启动流程 启动类为 QuorumPeerMain 解析 zoo.cfg 配置 创建并启动 DatadirCleanupManager 用于清理过期 snapshot 和 txnlog. 创建 QuorumPeer 实例并启动该线程,用于完成选举. 根据 snapshot 和 txnlog 恢复 内存数据库 ZKDatabase. 12345678910111213141516171819202122232425262728293031323334353637383940- QuorumPeerMain.main()- 1.创建QuorumPeerMain对象- 2.初始化 运行 main.initializeAndRun(args) - 0.创建QuorumPeerConfig对象 - 1.通过QuorumPeerConfig.parse(),解析配置文件 - 读取zoo.cfg配置到Properties中 - parseProperties()解析Properties配置到QuorumPeerConfig对象中 -...

zk idea 代码阅读环境搭建采用最新的 zookeeper release 版本 3.4.13zk发行版下载地址 从 github 上 clone 该版本的代码. 1. ant 构建 zkbuild.xml 搜索 ant-eclipse-1.0.bin.tar.bz2, 1290行修改 12<get src="http://ufpr.dl.sourceforge.net/project/ant-eclipse/ant-eclipse/1.0/ant-eclipse-1.0.bin.tar.bz2"dest="${src.dir}/java/ant-eclipse-1.0.bin.tar.bz2" usetimestamp="false" /> 执行 ant eclipse 2. idea 导入这个 eclipse 项目即可File -> New -> import project from exist source -> 选eclipse 将...

zk选举完后数据同步流程Leader为每个Follower/observer都建立一个TCP长连接. LearnerHandler,即learner服务器的管理者,负责follower/observer服务器和leader服务器之间的一系列网络通信.包括数据同步,请求转发和Proposal提议的投票等. leader.lead();->leader 从磁盘中恢复数据和session列表Leader zk.loadData();->Leader 启动监听线程 LearnerCnxAcceptor, 等待新的followers的连接请求->follower 连接leaderFollower follower.followLeader();->LearnerCnxAcceptor 监听到follower的socket请求,为每个 follower 创建单独的 LearnerHandler 线程用于交互.->follower 发送 FOLLOWERINFO 包 给leader,包括新的zxid​和 sidFollower...