【JAVA高并发-1】必备技能

1.1 Netty

Netty是JBOSS提供的一个Java开源框架，是基于NIO的客户端/服务器编程框架，既能快速开发高并发、高可用、高可靠的网络服务器程序，也能开发高可用、高可靠的客户端程序。

1.1.1 Netty火热的程度

• Netty具有大量分布式中间件、各种开源项目以及各种商业项目的应用
• 提供了异步的、事件驱动的网络应用程序框架和工具，所有IO操作都是异步非阻塞的，通过Future-Listener机制，用户可以方便地主动获取或者通过通知机制获得IO操作结果。
• 提供了十分简单易用的API，非常适合网络编程。
• 优点：
  • API使用简单，开发门槛低。
  • 功能强大，预置了多种编解码功能，支持多种主流协议。
  • 定制能力强，可以通过ChannelHandler对通信框架进行灵活扩展。
  • 性能高，与其他业界主流的NIO框架相比，Netty的综合性能最优。
  • 成熟、稳定，Netty修复了在JDK NIO中所有已发现的Bug，业务开发人员不需要再为NIO的Bug而烦恼。
  • 社区活跃，版本迭代周期短，发现的Bug可以被及时修复。

1.1.2 面试杀器

1.2 Redis

1.2.1 什么是Redis

Redis是**Remote Dictionary Server（远程字典服务器）**的缩写，最初是作为数据库的工具来使用的，是目前使用广泛、高效的开源缓存。

• 使用c语言开发，将数据保存在内存中，可以看成一款纯内存的数据库，数据存取速度非常快。
• 通过键值对形式来存储数据，类似JAVA中的映射。
  • Key只能是String类型
  • Value可以是String类型、Map类型、List（列表）类型、Set（集合）类型、SortedSet（有序集合）类型。
• Redis的主要应用场景是缓存（数据查询、短连接、新闻内容、商品内容等）、分布式会话（Session）、聊天室的在线好友列表、任务队列（秒杀、抢购、12306等）、应用排行榜、访问统计、数据过期处理（可以精确到毫秒）。

1.2.2 Redis特点

• 速度快。不需要等待磁盘的IO，而是在内存之间进行数据存储和查询，缓存的数据总量受到物理内存空间大小的限制。
• 丰富的数据结构，有String、List、Hash、Set、SortedSet五种类型。
• 单线程，避免了线程切换和锁机制的性能消耗。
• 可持久化。支持RDB与AOF两种方式，将内存中的数据写入外部的物理存储设备。
• 支持发布/订阅。
• 支持Lua脚本。
• 支持分布式锁。在分布式系统中，不同的节点需要访问同一个资源时，往往需要通过互斥机制来防止彼此干扰，并且保证数据的一致性。在这种情况下，需要用到分布式锁。分布式锁和Java的锁用于实现不同线程之间的同步访问，原理上是类似的。
• 支持原子操作和事务。Redis事务是一组命令的集合。一个事务中的命令要么都执行，要么都不执行。如果命令在运行期间出现错误，不会自动回滚。
• 支持主-从（Master-Slave）复制与高可用（Redis Sentinel）集群（3.0版本以上）。
• 支持管道。Redis管道是指客户端可以将多个命令一次性发送到服务器，然后由服务器一次性返回所有结果。管道技术的优点是，在批量执行命令的应用场景中，可以大大减少网络传输的开销，提高性能。

1.3 ZooKeeper

1.3.1 什么是ZooKeeper

ZooKeeper最早起源于雅虎公司研究院的一个研究小组。当时，研究人员发现，在雅虎内部很多大型的系统需要依赖一个类似的系统进行分布式协调，但是这些系统往往存在分布式单点问题，所以雅虎的开发人员就试图开发一个通用的无单点问题的分布式协调框架。
此框架的命名过程也是非常有趣的。在项目初期给这个项目命名时，准备和很多项目一样，按照雅虎公司的惯例使用动物的名字来命名（例如著名的Pig项目）。在探讨取什么名字的时候，研究院的首席科学家Raghu Ramakrishnan开玩笑说：“再这样下去，我们这儿就变成动物园了。”此话一出，大家纷纷表示新框架就叫动物园管理员吧，于是ZooKeeper（动物园管理员）诞生了。而ZooKeeper正好是用来协调分布式环境的不同节点的，形象地说，可以理解为协调各个以动物命名的分布式组件，所以ZooKeeper也就“名副其实”了。

1.3.2 ZooKeeper优势

• 核心优势：实现了分布式环境的数据一致性，不会引起“脏读”“幻读”“不可重复读”问题
  • “脏读”：一个事务中访问到了另外一个事务未提交的数据
  • “不可重复读”：一个事务内根据同一个条件对数据进行多次查询，但是结果却不一致，原因是其他事务对改数据进行了修改
  • “幻读”：当两个完全相同的查询执行时，第二次查询所返回的结果集合第一次查询所返回的结果集不相同，原因也是另外一个事务新增、删除了第一个事务结果集中的数据。
• ZooKeeper对不同系统环境的支持都很好，但不建议在FreeBSD系统上部署ZooKeeper生产服务器
• 可以借助ZooKeeper来达到高吞吐、低延迟

1.4 高性能HTTP通信技术

1.4.1 十万级以上高并发场景中的高并发HTTP通信技术

• 服务层——执行Java应用程序。
  • 传统单体应用——执行在Tomcat服务器上
  • Spring Cloud分布式应用——执行在内嵌的Tomcat服务器上
• 接入层——完成鉴权、限流、反向代理和负载均衡等功能。
• 客户端层

对于千万级QPS的Web应用，除了服务层的独立Tomcat或者Spring Cloud微服务节点需要进行不断的横向扩展之外，还需要进行以下两大增强：

• 引入LVS负载均衡层，进行请求分发和接入层的负载均衡。
• 引入DNS服务器的负载均衡，可以在域名下面添加多个IP，由DNS服务器进行多个IP之间的负载均衡，甚至可以按照就近原则为用户返回最近的服务器IP地址。

1.4.2 微服务之间的高并发RPC技术

在基于SpringCloud技术架构的分布式WEB应用中，微服务Provider（服务节点）之间存在着大量的RPC
微服务Provider实例之间的RPC在SpringCloud全家桶技术体系中是由Feign基于Ribbon完成的，并由Hystrix组件提供RPC的熔断、回退、限流等保护。
springcloud并没有提供高性能RPC通信（HTTP通信）的技术方案，通过配置可以借助Apache HttpClient 或者OkHttp等通信组件实现HTTP高性能通信。由于HTTP高性能通信设计底层socket连接（TCP连接）的复用管理，甚至涉及TCP/HTTP等一系列非常基础、原理的知识。

1.5 高并发IM的总和实战

1.5.1 高并发IM的学习价值

首先，通过实战完成一个分布式、高并发的IM系统具有相当大的技术挑战性。对于传统的企业级Web开发者来说，这相当于进入了一片全新的天地。企业级Web的QPS峰值可能在1000以内，甚至100以内，没有多少技术挑战性和含金量，属于重复性的CRUD（Create，创建；Retrieve，查询；Update，更新；Delete，删除）的体力活。一个分布式、高并发的IM系统面临的QPS峰值可能在十万、百万、千万甚至上亿级别。层次化、递进的高并发需求将无极限地考验着系统的性能，从通信协议到系统的架构需要不断地进行优化，这对技术能力是一种非常极致的考验和训练。
其次，就具有不同QPS峰值规模的IM系统而言，它们所处的用户需求环境是不一样的。这就造成了不同用户规模的IM系统各自具有一定的市场需求和实际需要，因而它们不一定都需要上亿级的高并发。但是，作为一个顶级的架构师，应该具备全栈式的架构能力，对不同用户规模、差异化的应用场景构建出相匹配的高并发IM系统。也就是说，IM系统的综合性相对较强，相关的技术涉及满足各种不同应用场景的网络传输、分布式协调、分布式缓存、服务化架构等方面。

1.5.2 庞大的应用场景

可以说，大部分高并发实时通信、消息推送的应用场景都需要高并发IM。随着移动互联网、AI的飞速发展，高性能、高并发IM有着非常广泛的应用场景。
高并发IM典型的应用场景有私信、聊天、大规模推送、弹幕、实时定位、在线教育、智能家居、互动游戏、抽奖等.
尤其是对于从事APP开发的小伙伴来说，IM已经成为大多数APP的标配。在移动互联网时代，推送（Push）服务成为APP不可或缺的重要组成部分，可以提升用户的活跃度和留存率。我们的手机每天接收到各种各样的广告和提示消息等，其中大多数都是通过推送服务实现的。
随着5G时代物联网的发展，未来所有接入物联网的智能设备都将是IM系统的客户端，这就意味着推送服务会在未来面临海量的设备和终端接入。为了支持这些千万级、上亿级的终端，一定需要强悍的后台系统。