1、什么是Mybatis？
1、Mybatis 是一个半 ORM（ 对象关系映射）框架，它内部封装了 JDBC，开发时只需要关注 SQL 语句本身， 不需要花费精力去处理加载驱动、创建连接、创建
statement 等繁杂的过程。程序员直接编写原生态 sql，可以严格控制 sql 执行性能， 灵活度高。
2、MyBatis 可以使用 XML 或注解来配置和映射原生信息， 将 POJO 映射成数据库中的记录， 避免了几乎所有的 JDBC 代码和手动设置参数以及获取结果集。
3、通过 xml 文件或注解的方式将要执行的各种 statement 配置起来， 并通过java 对象和 statement 中 sql 的动态参数进行映射生成最终执行的 sql 语句，最后由 mybatis 框架执行 sql 并将结果映射为 java 对象并返回。（ 从执行 sql 到返回 result 的过程）。
2、Mybaits 的优点：
1、基于 SQL 语句编程，相当灵活，不会对应用程序或者数据库的现有设计造成任何影响，SQL 写在 XML 里，解除 sql 与程序代码的耦合，便于统一管理；提供 XML 标签， 支持编写动态 SQL 语句， 并可重用。
2、与 JDBC 相比，减少了 50% 以上的代码量，消除了 JDBC 大量冗余的代码，不需要手动开关连接；
3、很好的与各种数据库兼容（ 因为 MyBatis 使用 JDBC 来连接数据库，所以只要JDBC 支持的数据库 MyBatis 都支持）。
4、能够与 Spring 很好的集成；
5、提供映射标签， 支持对象与数据库的 ORM 字段关系映射； 提供对象关系映射标签， 支持对象关系组件维护。
1、SQL 语句的编写工作量较大， 尤其当字段多、关联表多时， 对开发人员编写SQL 语句的功底有一定要求。
2、SQL 语句依赖于数据库， 导致数据库移植性差， 不能随意更换数据库。
MyBatis部分
ZooKeeper 是一个开放源码的分布式协调服务， 它是集群的管理者， 监视着集群中各个节点的状态根据节点提交的反馈进行下一步合理操作。最终， 将简单易用的接口和性能高效、功能稳定的系统提供给用户。
分布式应用程序可以基于 Zookeeper 实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。
1、顺序一致性
2、原子性
3、单一视图
4、可靠性
5、实时性（ 最终一致性）
客户端的读请求可以被集群中的任意一台机器处理， 如果读请求在节点上注册了监听器，这个监听器也是由所连接的 zookeeper 机器来处理。对于写请求，这些请求会同时发给其他 zookeeper 机器并且达成一致后，请求才会返回成功。因此， 随着 zookeeper 的集群机器增多，读请求的吞吐会提高但是写请求的吞吐会下降。
有序性是 zookeeper 中非常重要的一个特性， 所有的更新都是全局有序的， 每个更新都有一个唯一的时间戳，这个时间戳称为 zxid（ Zookeeper Transaction Id）。而读请求只会相对于更新有序， 也就是读请求的返回结果中会带有这个
zookeeper 最新的 zxid。
1、文件系统
2、通知机制
Zookeeper 提供一个多层级的节点命名空间（ 节点称为 znode）。与文件系统不同的是， 这些节点都可以设置关联的数据， 而文件系统中只有文件节点可以存放数据而目录节点不行。
Zookeeper 为了保证高吞吐和低延迟， 在内存中维护了这个树状的目录结构， 这种特性使得 Zookeeper 不能用于存放大量的数据， 每个节点的存放数据上限为1M。
ZAB 协议是为分布式协调服务 Zookeeper 专门设计的一种支持崩溃恢复的原子广播协议。
ZAB 协议包括两种基本的模式： 崩溃恢复和消息广播。
当整个 zookeeper 集群刚刚启动或者 Leader 服务器宕机、重启或者网络故障导致不存在过半的服务器与 Leader 服务器保持正常通信时，所有进程（ 服务器）进入崩溃恢复模式， 首先选举产生新的 Leader 服务器， 然后集群中 Follower 服务器开始与新的 Leader 服务器进行数据同步， 当集群中超过半数机器与该 Leader 服务器完成数据同步之后， 退出恢复模式进入消息广播模式， Leader 服务器开始接收客户端的事务请求生成事物提案来进行事务请求处理。
ZooKeeper部分
随着服务化的进一步发展， 服务越来越多， 服务之间的调用和依赖关系也越来越复杂， 诞生了面向服务的架构体系(SOA)，
也因此衍生出了一系列相应的技术， 如对服务提供、服务调用、连接处理、通信协议、序列化方式、服务发现、服务路由、日志输出等行为进行封装的服务框架。
就这样为分布式系统的服务治理框架就出现了， Dubbo 也就这样产生了。
接口服务层（ Service）：该层与业务逻辑相关，根据 provider 和 consumer 的业务设计对应的接口和实现
配置层（ Config）：对外配置接口，以 ServiceConfig 和 ReferenceConfig 为中心
服务代理层（ Proxy）：服务接口透明代理，生成服务的客户端 Stub 和 服务端的 Skeleton， 以 ServiceProxy 为中心， 扩展接口为 ProxyFactory
服务注册层（ Registry） ： 封装服务地址的注册和发现， 以服务 URL 为中心， 扩展接口为 RegistryFactory、Registry、RegistryService
路由层（ Cluster） ： 封装多个提供者的路由和负载均衡， 并桥接注册中心， 以Invoker 为中心， 扩展接口为 Cluster、Directory、Router 和 LoadBlancce
监控层（ Monitor） ： RPC 调用次数和调用时间监控， 以 Statistics 为中心， 扩展接口为 MonitorFactory、Monitor 和 MonitorService
远程调用层（ Protocal）：封装 RPC 调用，以 Invocation 和 Result 为中心， 扩展接口为 Protocal、Invoker 和 Exporter
信息交换层（ Exchange）： 封装请求响应模式， 同步转异步。以 Request 和Response 为中心， 扩展接口为 Exchanger、ExchangeChannel、ExchangeClient 和 ExchangeServer
网络传输层（ Transport）：抽象 mina 和 netty 为统一接口，以 Message 为中心， 扩展接口为 Channel、Transporter、Client、Server 和 Codec
数据序列化层（ Serialize） ： 可复用的一些工具， 扩展接口为 Serialization、ObjectInput、ObjectOutput 和 ThreadPool
默认也推荐使用 netty 框架， 还有 mina。
Dubbo部分
其他部分
如果本文对你有帮助，别忘记给我个3连 ，点赞，转发，评论，
学习更多JAVA知识与技巧，关注与私信博主（888）
| 留言与评论（共有 0 条评论） “” |
