golang里可以通过关键字go很简单的开启一个协程，但是如果开启协程的速度超过回收的速度，就会导致协程泄露。本文就介绍如何通过设计一个安全的协程池来避免出现协程泄露的问题。

协程池

一个包含多个工作协程，且能同时支持并行执行任务的数据结构

实现

协程池分两种类型，一种是worker数量固定的协程池，一种是worker数量可自动伸缩的协程池

接口定义：

1
2
3
4
5
6
7

type GoroutinePool interface {
	// Schedule 调度worker执行任务
	Schedule(task func())

	// Stop 停止工作
	Stop()
}

以下是具体实现：

在网络传输过程中，如果遇到体量较大的数据，我们一般采用压缩算法，实现减少带宽占用的做法。

GZIP

gzip是GNUzip的缩写，最早用于UNIX系统的文件压缩。
GZIP 的核心是 Deflate,Deflate 是一个同时使用 LZ77 与 Huffman Coding 的算法。

原理

gzip 对于要压缩的文件，首先使用LZ77算法的一个变种进行压缩，对得到的结果再使用Huffman编码的方法进行压缩。

LZ77

核心思路是如果一个串中有两个重复的串，那么只需要知道第一个串的内容和后面串相对于第一个串起始位置的距离 + 串的长度。

比如： ABCDEFGABCDEFH → ABCDEFG(7,6)H。7 指的是往前第 7 个数开始，6 指的是重复串的长度，ABCDEFG(7,6)H 完全可以表示前面的串，并且是没有二义性的。

Huffman

核心思路是通过构造 Huffman Tree 的方式给字符重新编码（核心是避免一个叶子的路径是另外一个叶子路径的前缀），以保证出现频路越高的字符占用的字节越少。

实现

下面介绍的是在golang里如何使用gzip实现解压缩操作

前面我们介绍了如何设计一个高性能tcp框架，现在我们基于该框架，利用较少的硬件资源，实现一个支持百万连接的实时聊天(IM)服务

即时通讯

即时通信（ IM ）是指能够即时发送和接收 互联网 消息等的业务。

功能设计

本文将围绕以下三个基础功能来实现一个简易但性能强悍的IM

• 私信聊天：用户A可以向用户B发送消息，系统将该消息写入用户B的信箱。
• 群组聊天：用户A加入某个群组后发送消息，系统将该消息直接广播给其他群组成员。
• 查询历史消息：用户可以指定某个聊天会话查询历史消息。

扩展

以下功能不做实现，但如果一个更完善的IM服务，需要具备以下特性，这里只是简单介绍下方案：

• 如何保证消息的顺序性?

  消息ID采用可比较性的规则，比如Mongo的ObjectID，Snowflake算法，或者时间戳+随机字符串。客户端根据消息ID来排序显示。

• 如何保证消息的可达率？

  私信消息先写入信箱，然后给客户端发送新消息通知，让客户端来读取信箱，读取后删除已读消息。
  群聊消息采用广播的方式，直接给在线的客户端推送消息，不需要做消息回执。离线用户上线后通过拉取历史数据来读取离线消息。

• 如何解决带宽占用太高？

  IM服务里群聊消息广播是带宽占用太高的大头，可以通过以下策略对进行省流：
  1.设置默认不接收群聊推送，减少群聊消息的推送量
  2.将一个时间片内的消息合并后再推送，同时设置推送的消息条数上限。丢弃多余消息条数，以提供获取历史消息的方式，按照用户触发去查询完整的消息列表。
  3.利用压缩算法(如gzip)对消息内容进行压缩

• 如何优化超大群的消息体验？
  对于千人/万人/十万人的大群，提高聊天体验，可以从延时性，每秒消息条数等方面入手。

  1.降低延时：可以按照分片的设计思想，将大量的连接数平均分配到多个分片里，通过多线程的方式同时对分片内的连接推送消息，比如一个十万人的大群，分成1024个分片，每个分片负责100人的推送任务。
  2.每秒接收消息条数: 首先限制客户端的发言频率，其次是限制每秒推送的消息总条数。当每秒产生的消息超过上限时，可以采取丢弃或补全策略。
  a)丢弃策略：通过限流算法，按照每个会话设置每秒请求数，超过上限的直接不处理。如腾讯采用的策略是每秒40条上限，超过则丢弃。
  b)补全策略：全部接收并处理，只是推送时，推送最新N条消息而非全部，设计消息Sequence字段，第n条消息的Sequence字段值为n。客户端根据该字段进行判断是否有消息断层，如果有，通过拉取历史消息来补全，保证会话的完整性。

(PS：我参加的某个游戏聊天综合项目采用补全策略，必须吐槽下。需求方面，切换会话可以通过拉取历史来查看完整的消息列表，出现消息断层的情况只会出现在消息量太大且用户正聚焦在此会话，当消息量太大还补全个毛线。技术方面，客户端实力不行，设计好的补全策略的逻辑都搞不清，加上涉及本地缓存等复杂逻辑，脑子都是懵的，两个字：辣鸡)

• 如何选择聊天数据的存储方案和过期策略？

  可以根据服务的架构来确定存储方案，如下：
  1.单点服务：可以采用内存+持久性存储(MongoDB/ElasticSearch等)
  2.分布式服务：可以采用分布式缓存(Redis)+持久性存储(MongoDB/ElasticSearch等)
  可以根据聊天类型设置过期策略，以分布式服务为例，策略如下：
  1.私信为高级，可以采用Redis+Mongo的混合式存储，Redis设置较长的过期时间，Mongo永久存储。缓存过期后可以从Mongo中读取后再次加载到Redis中。且根据会话设置较大的消息条数上限，超过则删除更早的数据。
  2.小群为中级，只采用Redis存储，Redis设置较长的过期时间，且根据会话设置较大的消息条数上限，超过则删除更早的数据
  3.大群为低级，只采用Redis存储，Redis设置较短的过期时间，且根据会话设置较小的消息条数上限，超过则删除历史数据。

前面介绍了Epoll,Reactor等等，本文主要是介绍高性能Socket框架的设计思路以及各个模块的调用时序。

更多请参考：我的自研网络框架 znet，欢迎Star与提Issue。

整体设计

想要达到高性能的目标，首先必须在整体方面有良好的设计。

模块设计

• Network：Socket服务的总控，负责初始化和管理各个子模块。
• Acceptor: 连接接收模块，负责与客户端建立连接。
• Reactor: 事件调度主模块，负责监听活跃连接以及注册回调事件(OnOpen/OnClose/OnMessage/OnError)。
• SubReactor: 事件调度子模块，负责管理连接，以及执行新消息回调事件。
• Thread: 多线程事件处理模块，利用协程池并发处理客户端请求，包括读取、解包、处理逻辑、打包、发送数据等操作。
• Connection: 客户端连接抽象对象，同时支持TCP/WebSocket协议的连接。
• Context: 请求上下文对象，负责携带客户端请求数据。
• Engine: 请求处理引擎，负责执行Context。采用责任链的设计模式，提供注入中间件的使用方式。
• Router：路由模块，细化请求处理回调事件，允许按照Action来注入处理客户端请求的Handler。

上一篇文章介绍了reactor模型，本文介绍如何通过reactor模型监听TCP连接

更多请参考：我的自研网络框架 znet，欢迎Star与提Issue。

Reactor实现方案

• 方案一：单进程/线程，启动单个Reactor，单个Acceptor。不用考虑进程间通信以及数据同步的问题,无法充分利用多核CPU。处理业务逻辑的时间不能太长，否则会延迟响应，所以不适用于计算机密集型的场景。
• 方案二：单进程/多线程，启动单个Reactor,多个Acceptor。解决方案一的问题无法利用多核CPU的问题。但是它依然只有一个主线程处理业务，无法解决瞬时高并发带来的性能问题。
• 方案三：多进程/多线程，启动多个Reactor(一个MainReactor+多个SubReactor)，多个Acceptor。主 Reactor 只负责监听事件，响应事件的工作交给了从 Reactor。

模块设计

• Acceptor: 负责与客户端建立链接，并将连接发送给Reactor
• Reactor: 通过Epoll负责注册连接与监听活跃连接
• SubReactor: 负责管理连接,可支持分片特性，提高吞吐
• Thread: 负责处理数据包的接收、解包、打包、发送,可支持多线程并发处理

流程设计

参考网图：

本文将Reactor并发模型与Epoll的实现

更多请参考：我的自研网络框架 znet，欢迎Star与提Issue。

Reactor

Reactor模式，是指通过一个或多个输入同时传递给服务处理器的服务请求的事件驱动处理模式。

• 普通的函数处理机制为：调用某函数-> 函数执行， 主程序等待阻塞-> 函数将结果返回给主程序-> 主程序继续执行。
• Reactor 事件处理机制为：主程序将事件以及对应事件处理的方法在 Reactor 上进行注册，如果相应的事件发生，Reactor 将会主动调用事件注册的接口，即 回调函数。

交互图如下（来自网络）：

为什么要用Reactor模型

相比常规模式的为每个连接开启一个线程来读取和写入数据，Reactor模型只需要一个主线程就能管理所有的连接。这样可以极大的节省内存占用。

Epoll

epoll 全称 eventpoll，是 linux 内核实现IO多路复用（IO multiplexing）的一个实现。IO多路复用的意思是在一个操作里同时监听多个输入输出源，在其中一个或多个输入输出源可用的时候返回，然后对其的进行读写操作。

linux下主要是通过epoll实现的reactor模型。

本文介绍如何给tcp连接增加回调函数，和websocket一样，提供三个回调函数:OnOpen,OnClose,OnMessage。

更多请参考：我的自研网络框架 znet，欢迎Star与提Issue。

回调函数

• OnOpen: 连接建立成功后触发的回调函数。
• OnClose: 连接断开后触发的回调函数。
• OnMessage: 收到新消息时的回调函数。

实现

前面已经提到如何启动一个TCP服务，具体请点击：TCP编程。我们在此基础上去添加回调函数。

• Callback

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

  package network import "net" type ConnectionHandler func(conn *net.TCPConn) // Callback manage connection callback handlers. type Callback struct { open ConnectionHandler close ConnectionHandler request func(conn *net.TCPConn, msg []byte) } // triggerOpenEvent is called when the connection is established func (callback *Callback) triggerOpenEvent(conn *net.TCPConn) { if callback.open != nil { callback.open(conn) } } // triggerCloseEvent is called when the connection is closed func (callback *Callback) triggerCloseEvent(conn *net.TCPConn) { if callback.close != nil { callback.close(conn) } } // triggerRequestEvent is called when receive new message func (callback *Callback) triggerRequestEvent(conn *net.TCPConn, msg []byte) { if callback.request != nil { callback.request(conn, msg) } }

本文介绍在golang的socket编程中，对粘包问题的处理方式。

粘包

因为TCP是面向流，没有边界，而操作系统在发送TCP数据时，会通过缓冲区来进行优化，例如缓冲区为1024个字节大小。

• 如果一次请求发送的数据量比较小，没达到缓冲区大小，TCP则会将多个请求合并为同一个请求进行发送，这就形成了粘包问题。
• 如果一次请求发送的数据量比较大，超过了缓冲区大小，TCP就会将其拆分为多次发送，这就是拆包。

1

PS: websocket通过底层协议帧解决的粘包问题。

常见的解决方案

• 将消息分为头部和消息体，头部中保存整个消息的长度，只有读取到足够长度的消息之后才算是读到了一个完整的消息(常用)
• 通过自定义协议进行粘包和拆包的处理
• 发送端在每个包的末尾使用固定的分隔符，例如\r\n。
• 发送端将每个包都封装成固定的长度，比如100字节大小。

在参加的某次架构师考试中，遇到了关于一致性哈希算法的问题.平时对哈希算法比较了解，并未深入了解一致性哈希,今天就来盘一盘。

什么是一致性哈希算法

一致性哈希算法在1997年由麻省理工学院提出，是一种特殊的哈希算法，目的是解决分布式缓存的问题。 [1] 在移除或者添加一个服务器时，能够尽可能小地改变已存在的服务请求与处理请求服务器之间的映射关系。一致性哈希解决了简单哈希算法在分布式哈希表( Distributed Hash Table，DHT) 中存在的动态伸缩等问题。

与哈希算法的区别

• 哈希算法
  使用简单的哈希函数: m = hash(o) mod n,其中，o为对象名称，n为机器的数量，m为机器编号。

因为对同一个关键字进行哈希计算，每次计算都是相同的值，这样就可以将某个 key 确定到一个节点了，可以满足分布式系统的负载均衡需求。

但如果节点数量发生了变化，也就是在对系统做扩容或者缩容时，必须迁移改变了映射关系的数据，否则会出现查询不到数据的问题。

• 一致性哈希算法
  一致性hash算法正是为了解决此类问题的方法，它可以保证当机器增加或者减少时，节点之间的数据迁移只限于两个节点之间，不会造成全局的网络问题。

一致哈希算法也用了取模运算，但与哈希算法不同的是，哈希算法是对节点的数量进行取模运算，而一致哈希算法是对 2^32 进行取模运算，是一个固定的值。

最终我们可以把一致哈希算法是对 2^32 进行取模运算的结果值组织成一个圆环，被称为哈希环。
一致性哈希要进行两步哈希操作：
- 1.对存储节点进行哈希计算，也就是对存储节点做哈希映射，比如根据节点的 IP 地址获机器的唯一名称进行哈希
- 2.当对数据进行存储或访问时，对数据进行哈希映射
所以，一致性哈希是指将「存储节点」和「数据」都映射到一个首尾相连的哈希环上。
在对数据进行存取时，我们先对「数据」进行哈希映射，再根据结果值，往顺时针的方向遍历找到第一个「存储节点」,就用这个节点来存取数据。

所以在一致哈希算法中，如果增加或者移除一个节点，仅影响该节点在哈希环上顺时针相邻的后继节点，其它数据也不会受到影响。

在任务量大、性能要求高的场景，为了将任务存取及取消操作时间复杂度降为 O(1)，会采用时间轮算法

什么是时间轮计时器

为解决高效调度任务而产生的调度模型，主要应用在延迟大规模的延时任务、周期性的定时任务等场景。

设计思想

• 根据时针的转动，按时间刻度去触发定时任务的执行。
• 单级时间轮只能装载固定刻度的定时任务，而多级时间轮能包含更多的定时器。