Netty项目

一、项目构成

二、项目学到的知识

1）Netty框架

主从reactor模式

1. Reactor在一个单独的线程中负责监听和分发事件
2. 主Reactor只处理“accept”事件，从Reactor处理其他业务

Netty模型

1. BossGroup与WorkGroup都是NioEventLoopGroup（事件循环）
2. 其中都是多个NioEventLoop（上图中不对，上面的NioEventGroup）
3. 对于BossGroup中的每个NioEventLoop，是一个负责处理accept的事件循环：
   1.轮询accept事件
   2.处理accept事件，并与client建立连接，生成channel，并将channel传递给WorkGroup中的某一个NioEventLoop
   3.处理剩余的在任务队列中的任务
4. 对于WorkerGroup中的每个NioEventLoop，是负责IO业务的事件循环：
   1. 轮询IO事件
   2. 处理IO事件，会使用pipeline（刚才BossGroup中的提供了channel，而channel与pipeline是一对一的关系，能够互相得到对方），而pipeline中存在多个handler（比如encoderHandler，decoderHandler，自己编写的Handler）
   3. 处理任务队列其余任务
5. Remark：在WorkGroup中处理的时候不会被阻塞的，因为采用了异步的future-listener机制，比如write，connect等操作就会返回一个channelFuture。

2）为什么BossGroup设置一个NioEventLoop而WorkerGroup设置多个NioEventLoop？

因为BossGroup就是处理连接问题，连接成功后就将其的channel传递到workerGroup中进行IO操作。
而任何一个服务端与客户端连接一次就能得到channel，而连接以后IO的操作是很多的，故BossGroup设置一个即可。

3）信号量机制semaphore

1. 信号量常用于限制可以访问的某些资源的线程数量，那么我们想考虑一下Lock与semaphore的区别，重要特点是：semaphore允许多个线程访问同一个临界区。
2. 底层：抽象同步队列（AQS队列）
   1. 双向队列，内部是node节点
   2. 当一个线程实现了获取了ReentrantLock锁，在内部采用CAS操作把state状态由0到1，其他线程发现自己并不是该锁的持有者就会放进阻塞队列中
   3. 公平与非公平的实现：当我们在获取锁的时候需要CAS修改state的值，比如 semaphore，不公平——CAS时只检查state，公平——CAS时检查state且检查当前的阻塞队列有东西吗
   4. 不公平的吞吐量高于公平锁：在恢复一个被挂起的线程与该线程真正运行之间存在着严重的延迟（从阻塞队列中再唤醒就比较耗时）

thread	标记进入AQS队列的是哪个线程
state	对于ReentrantLock：标记可重入的次数；对于semaphore：当前可用信号的数

3. semaphore能实现“死锁恢复”，Lock则不行，因为semaphore能够通过一个非owner线程release一些线程，但是如果你用的是Lock，就不行，因为unlock必须先拥有这个对象，而非owner线程是无法拿到已经被owner线程占用的锁。
   
   

4）mysql为什么要分库分表

1. 由于当mysql存放了500W条数据时就会产生性能瓶颈。
2. 由于机器的真实物理内存有限，而虚拟内存是大于物理内存的，比如商品列表页面，正常时候是通过一次次的换页进行将外存的数据逐步换入内存，当超过500W条以后就会出现性能瓶颈，由于机器的物理内存无法支撑大规模拼烦的换页
3. 我们可以将其分为0~500W， 500W~1000w等几个数据库上
4. 怎么判断放进哪个数据库呢？答：根据一些属性的hash值，根据hash值存放到某台服务器上
5. 如何查询？几个库同时查询（不怎么耗时的，只需一个数据库的时间），查完之后再汇总

5) maven的包版本号不同的重复引用问题

问题简述：

1. 进行了重复引用同一个包,但是版本号不一致。
2. 这两个版本号中的引入方法不同，当调用时报错

1. 主要出问题的pom文件：
   注意：client与server都引入了nacos-client的1.4.1版本（自带Jackson-core 2.10.4版本），但是我们在common子模块中我们需要引入的是2.12.1版本的Jackson-core（父pom中规定好了）。

<dependencies>
        <dependency>
            <groupId>com.alibaba.nacos</groupId>
            <artifactId>nacos-client</artifactId>
            <version>1.4.1</version>
        </dependency>
        <dependency>
            <groupId>com.polyu</groupId>
            <artifactId>common</artifactId>
            <version>1.0-SNAPSHOT</version>
            <scope>compile</scope>
        </dependency>
        <dependency>
            <groupId>com.polyu</groupId>
            <artifactId>netty-client</artifactId>
            <version>1.0-SNAPSHOT</version>
            <scope>compile</scope>
        </dependency>
        <dependency>
            <groupId>com.polyu</groupId>
            <artifactId>netty-server</artifactId>
            <version>1.0-SNAPSHOT</version>
            <scope>compile</scope>
        </dependency>

    </dependencies>

这样时maven依赖图为：

2. 当我们删除上面的第一个依赖时。即

 <dependencies>
    
        <dependency>
            <groupId>com.polyu</groupId>
            <artifactId>common</artifactId>
            <version>1.0-SNAPSHOT</version>
            <scope>compile</scope>
        </dependency>
        <dependency>
            <groupId>com.polyu</groupId>
            <artifactId>netty-client</artifactId>
            <version>1.0-SNAPSHOT</version>
            <scope>compile</scope>
        </dependency>
        <dependency>
            <groupId>com.polyu</groupId>
            <artifactId>netty-server</artifactId>
            <version>1.0-SNAPSHOT</version>
            <scope>compile</scope>
        </dependency>

    </dependencies>

此时的maven依赖图为：

可以看到引入的是2.12.1版本的jackson-core，此时不会报错。

3. 原因：当引入的相同包版本号不一致时，优先级如下：
   
   由于层数少的优先，所以无论我们将nacos-client放在前面还是后面都会报错的。
4. 再次测试，单独开一个maven只引入这一个包，发现不会冲突：

都是2.10.4版本的，再次引入jackson-databind2.12.1包，结果：

网上解答：

可以看到，下面的层数最低（0）层，会覆盖掉nacos-client中的jackson-databind包（1层）。故使得nacos-client原本相同2.10.4的版本号，变为一个2.10.4另一个2.12.1。出现报错。

三、项目流程代码分析

1）Server端

1. 注册ZK
   ZKRegistry(registryAddress, “testYYB”)

四、项目测试

zookeeper单机测试

zookeeper联机测试3888

Nacos单机测试

Naocs联机3181

五、RPC的几种常见框架

1）dubbo

TCP传输协议，使用了高性能的NIO的Netty框架，Hessian的序列化。

在了解Dubbo之前，要先对Zookeeper有深入的理解，当理解了zookeeper后，Dubbo也就了无秘密了。

Zookeeper作为Dubbo服务的注册中心，Dubbo原先基于数据库的注册中心，没采用Zookeeper，Zookeeper一个分布式的服务框架，是树型的目录服务的数据存储，能做到集群管理数据 ，这里能很好的作为Dubbo服务的注册中心，Dubbo能与Zookeeper做到集群部署，当提供者出现断电等异常停机时，Zookeeper注册中心能自动删除提供者信息，当提供者重启时，能自动恢复注册数据，以及订阅请求。

2）hessian

基于HTTP协议传输，在性能方面还不够完美，负载均衡和失效转移依赖于应用的负载均衡器，Hessian的使用则与RMI类似，区别在于淡化了Registry的角色，通过显示的地址调用，利用HessianProxyFactory根据配置的地址create一个代理对象，另外还要引入Hessian的Jar包。

3）RMI

JAVA自带的RPC框架，序列化技术是Java自带的序列化。