1、时代背景
5G应用，多终端应用，物联网应用，小程序，工业互联，大数据应用等等大前端时代的到来，程序员不能只关注crud，因为以后的服务并发量只会越来越多。
高并发架构师、大数据架构师或者说java高级工程师现在才能找到一份好工作。
Netty（T-io），Redis、zookeeper、高性能http组件（Nginx）、java并发编程组件（JUC包）工作两年以后，必须熟练掌握。
2、netty框架
Netty是Jboss提供的一个Java开源网络编程框架，基于NIO的客户端、服务端编程框架，既能快速开发高并发、高可用、高可靠的网络服务器，也能开发客户端程序。
Kafka，RocketMQ，es搜索引擎，大数据处理Hadoop框架，还有RPC框架Dubbo都是用了Netty框架。
Netty火热的原因：提供了异步的、事件驱动的网络应用程序框架和工具。Netty的所有IO操作都是异步非阻塞的。和JDK提供的NIO相比，Netty提供了更加丰富的api。
1，api简单，开发门槛低
2，功能强大，支持很多主流协议和自定义协议
3，性能高，和其他主流的NIO框架比，Netty性能更高
4，成熟，生态好，社区活跃，并且修复了JDK当中Nio中所有已发现的bug
5，面试加分（巨加分），几乎所有的中间件的高性能通信与传输都和Netty有关。
3，高并发im项目
- 学习价值：高并发的im系统具有相当大的挑战性，对于传统的web开发者（Springboot）来说，相当于进入了一个全新的天地。一个企业级的web的qps可能在1000以内，大厂在上万，而且基本上按照常用的调优思路（多线程，加缓存，解耦，优化sql）就可以搞定（秒杀场景除外），而且大部分都是在干crud，没啥意思。
- 一个分布式的。高并发的IM系统的面临的QPS峰值可能在十万，百万，千万甚至上亿级别。如何规划项目架构，如何规划服务器资源，如果规划版本迭代，如果设置操作系统参数来能够容纳更多的socket连接，都非常考验程序员的基础知识。
4，IO读写的基本原理
官网原话
一个原则：操作系统将内存划分为两部分：一个是内核空间，一个是用户空间。在linux操作系统中，内核模块运行在内核空间，相应的进程处在内核态；用户程序运行在用户态，对应的进程处于用户态。
内核态的进程可以访问内核空间，也可以访问硬件设备（磁盘，网卡等）调用系统的一切资源，用户态的进程没有这样的权限，也不能直接调用内核代码定义的函数。并且每个用户态的进程都有一个单独的用户空间，他要想拿到内存或磁盘中的数据，只有将进程切换到内核态然后向内核发出指令，完成调用系统资源之类的操作。
用户态的进程进行系统调用后，也不是直接就从硬件里把这些数据读出来了。从硬件里读数据是由操作系统来干的。
缓冲区的概念：两个缓冲区，内核缓冲区，应用程序缓冲区。缓冲区的目的就是为了减少硬件之间频繁的物理交换。操作系统会对内核缓冲区进行监控，等待缓冲区达到一定大小后，再进行实际的物理设备的交换（实际的io处理）
io操作其实就是两个缓冲区之间的复制
个人理解
用户（指进程tomcat进程等）想要访问网卡数据，首先要从用户态切换到内核态，然后内核态进程可以直接调用操作系统的函数（read/write）来拿到网卡等的数据，然后操作系统在将数据读取到内核缓冲区，内核缓冲区在给用户缓冲区复制一份，从内核态切换到用户态，最后用户访问的是用户缓冲区复制出来的数据，（用户没有权限直接访问设备的数据，需要通过切换内核态进行调用数据，然后在将数据复制到用户缓冲区）
5，io模型
服务端高并发IO编程往往要求的性能都非常高，一般情况下需要选用高性能的IO模型。
四种io模型：
同步阻塞io：默认情况下，在Java应用程序进程中所有对socket连接进行的IO操作都是同步阻塞IO。
简单的说就是在内核缓冲区获取数据的这个时间，用户态进程得阻塞着，什么也干不了。
在即时通讯项目里，不会采用这种模型，因为一般情况下，是一个socket连接对应一个独立的线程，如果用这种模型，在高并发项目中，需要很多的线程来维护大量的socet连接，内存，线程之间的切换开销会很大，性能很低。
优点：应用程序开发简单，在阻塞等待数据的区间，用户线程挂起，基本不会占用太多的cpu资源。
一个socket只能对应一个线程
同步非阻塞io
（1）在内核数据没有准备好的阶段，用户线程发起IO请求时立即返回。所以，为了读取最终的数据，用户进程（或者线程）需要不断地发起IO系统调用
（2）内核数据到达后，用户进程（或者线程）发起系统调用，用户进程（或者线程）阻塞。内核开始复制数据，它会将数据从内核缓冲区复制到用户缓冲区，然后内核返回结果
（3）用户进程（或者线程）读到数据后，才会解除阻塞状态，重新运行起来。也就是说，用户空间需要经过多次尝试才能保证最终真正读到数据，而后继续执行。
同步非阻塞IO的优点是每次发起的IO系统调用在内核等待数据过程中可以立即返回，用户线程不会阻塞，实时性较好。
同步非阻塞IO的缺点是不断地轮询内核，并且还会不断的进行用户态和系统态之间的切换，这将占用大量的CPU时间，效率低下。总体来说，在高并发应用场景中，同步非阻塞IO是性能很低的，也是基本不可用的，一般Web服务器都不使用这种IO模型。在Java的实际开发中，不会涉及这种IO模型，但是此模型还是有价值的，其作用在于其他IO模型中可以使用非阻塞IO模型作为基础，以实现其高性能。
一个线程对应多个socket连接，但是这个”多“有限，因为线程同时还要轮询缓冲区
IO多路复用
（1）选择器注册。首先，将需要read操作的目标文件描述符（socket连接）提前注册到Linux的select/epoll选择器中，在Java中所对应的选择器类是Selector类。然后，开启整个IO多路复用模型的轮询流程。
（2）就绪状态的轮询。通过选择器的查询方法，查询所有提前注册过的目标文件描述符（socket连接）的IO就绪状态。通过查询的系统调用，内核会返回一个就绪的socket列表。当任何一个注册过的socket中的数据准备好或者就绪了就说明内核缓冲区有数据了，内核将该socket加入就绪的列表中，并且返回就绪事件。
（3）用户线程获得了就绪状态的列表后，根据其中的socket连接发起read系统调用，用户线程阻塞。内核开始复制数据，将数据从内核缓冲区复制到用户缓冲区。
（4）复制完成后，内核返回结果，用户线程才会解除阻塞的状态，用户线程读取到了数据，继续执行。
IO多路复用模型的优点是一个选择器查询线程可以同时处理成千上万的网络连接，所以用户程序不必创建大量的线程，也不必维护这些线程，从而大大减少了系统的开销。与一个线程维护一个连接的阻塞IO模式相比，这一点是IO多路复用模型的最大优势。
一个线程对应多个socket链接（成千上万的），前面只负责链接socket链接，然后在用户态转换系统态，将socket请求提交到选择器，后面的系统线程轮询选择器，如果选择器里有数据请求，就将这个请求通过操作系统查数据，查完数据存到系统缓冲区，然后复制一份给用户缓冲区，然后通知用户线程有数据了，用户线程在到用户缓冲区读数据
(将用户态转换和轮询选择器分开)
异步io
增加了一个回调操作，但是因为出现的晚，jdk对于他的支持并不完善，所以用的不多。
异步io模型是性能最高的一个模型。
目前高并发网络应用程序都是采用的io多路复用。
6，即时通讯程序可能遇到的问题
1，操作系统的限制
linux操作系统对文件的句柄数有限制，是1024，也就是说一个线程最多处理1024个socket连接，这是远远不够的
2，socket虽然是长链接，但是他能一直保持连接吗？
理论上是，但是实际上不是，所以我们在架构设计的时候就要考虑这种情况。
比如说服务器防火墙会关闭不活跃的连接（最常见），比如说由于网络丢包或者网络波动等等都可能造成socket的不正常关闭。
理论上讲，关闭socket连接会有一个按钮，比如说下线，这个是正常关闭socket连接，但是也百分之99的人不会点下线，而是直接关闭整个app，这个时候socket就是不正常关闭了，不正常关闭会造成什么问题呢？
socket不正常关闭会造成网络连接假死。
网络连接假死：
如果底层的socket已经断开，但是服务端并没有正常关闭，服务端认为这条TCP连接仍然是存在的，则该连接处于“假死”状态。连接假死的会造成什么问题：
服务端长时间运行后会面临大量假死连接得不到正常释放的情况。由于每个连接都会耗费CPU和内存资源，因此大量假死的连接会逐渐耗光服务器的资源，使得服务器越来越慢，IO处理效率越来越低，最终导致服务器崩溃。
怎么解决呢：客户端定时发送心跳检测、服务端定时进行空闲检测。
3，分布式IM系统会有哪些问题？用户a和用户b链接的不同服务器，a想给b发数据但是却在服务器上找不到b的socket链接
4，IM系统部署建议使用传统的jar包部署，如果用k8s自动部署的话，自动扩容一个服务器，但是socket链接不变，还是连接的原来的服务器，
5，用户将客户端进程关闭，还怎么实现消息推送
方法1：流氓做法（几年前的方案）
ios系统（假后台）因为有自己的推送中心，所以socket服务器直接像苹果推送平台推消息就行了，但是安卓没有（国内给禁了），前几年基本上都是采用的流氓的做法：后台偷偷唤醒app进程，或者别的app启动时唤醒其他app的进程。
方法2：采用推送平台：比如说极光推送，对接统一推送联盟
chatService架构
涵盖了分布式应用需要的所有技术
全链路追踪：记录程序之间调用耗时，谁调的谁
