atom.xml

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
    <id>https://zhangyaoo.github.io</id>
    <title>will</title>
    <updated>2022-04-22T03:19:10.986Z</updated>
    <generator>https://github.com/jpmonette/feed</generator>
    <link rel="alternate" href="https://zhangyaoo.github.io"/>
    <link rel="self" href="https://zhangyaoo.github.io/atom.xml"/>
    <subtitle>生死看淡，不服就干</subtitle>
    <logo>https://zhangyaoo.github.io/images/avatar.png</logo>
    <icon>https://zhangyaoo.github.io/favicon.ico</icon>
    <rights>All rights reserved 2022, will</rights>
    <entry>
        <title type="html"><![CDATA[基于Netty的IM系统设计与实现]]></title>
        <id>https://zhangyaoo.github.io/post/ji-yu-netty-ji-shi-tong-xun-xi-tong-she-ji-yu-shi-xian/</id>
        <link href="https://zhangyaoo.github.io/post/ji-yu-netty-ji-shi-tong-xun-xi-tong-she-ji-yu-shi-xian/">
        </link>
        <updated>2021-12-01T04:02:35.000Z</updated>
        <content type="html"><![CDATA[<h2 id="im系列文章">IM系列文章</h2>
<ol>
<li><a href="#1-im%E6%9E%B6%E6%9E%84%E5%9B%BE">IM系统业务认知,微博信息流业务与直播业务区别</a></li>
<li><a href="#1-im%E6%9E%B6%E6%9E%84%E5%9B%BE">IM架构设计与实现，架构设计难点</a></li>
<li><a href="#1-im%E6%9E%B6%E6%9E%84%E5%9B%BE">IM架构设计与实现，HTTPDNS和LSB负载均衡设计</a></li>
<li><a href="#1-im%E6%9E%B6%E6%9E%84%E5%9B%BE">IM架构设计与实现，长连接网关设计和实现</a></li>
<li><a href="#1-im%E6%9E%B6%E6%9E%84%E5%9B%BE">消息可靠性、即时性、顺序性如何保证，消息通知机制</a></li>
<li><a href="#1-im%E6%9E%B6%E6%9E%84%E5%9B%BE">自定义协议架构和设计,全双工和网络收发模型</a></li>
<li><a href="#1-im%E6%9E%B6%E6%9E%84%E5%9B%BE">未读数如何设计,系统未读数和群聊未读数如何设计</a></li>
<li><a href="#1-im%E6%9E%B6%E6%9E%84%E5%9B%BE">群聊设计与实现，性能问题读扩散or写扩散</a></li>
<li><a href="#1-im%E6%9E%B6%E6%9E%84%E5%9B%BE">IM系统高可用如何实现</a></li>
</ol>
<h2 id="一-功能">一、功能</h2>
<p>简介：🚀FastIM是基于Netty高可用分布式即时通讯系统，支持长连接网关管理、单聊、群聊、聊天记录查询、离线消息存储、消息推送、心跳、分布式唯一ID、红包、消息同步等功能，支持集群部署的分布式架构。<br>
链接：https://github.com/zhangyaoo/fastim</p>
<h2 id="二-系统设计">二、系统设计</h2>
<h3 id="1-im架构图">1. IM架构图</h3>
<p>基于可扩展性高可用原则，把网关层、逻辑层、数据层分离，并且支持分布式部署<br>
<img src="https://zhangyaoo.github.io/post-images/architecture_new.png" alt="IM架构图" loading="lazy"></p>
<h3 id="2-架构设计">2. 架构设计</h3>
<h4 id="20-client设计">2.0 CLIENT设计：</h4>
<ol>
<li>client每个设备会在本地存每一个会话，保留有最新一条消息的顺序 ID</li>
<li>为了避免client宕机，也就是退出应用，保存在内存的消息ID丢失，会存到本地的文件中</li>
<li>client需要在本地维护一个等待ack队列，并配合timer超时机制，来记录哪些消息没有收到ack：N，以定时重发。</li>
<li>客户端本地生成一个递增序列号发送给服务器，用作保证发送顺序性。该序列号还用作ack队列收消息时候的移除。</li>
</ol>
<h5 id="21-客户端序列号设计">2.1 客户端序列号设计</h5>
<h5 id="方案一">方案一</h5>
<figure data-type="image" tabindex="1"><img src="https://zhangyaoo.github.io/post-images/sequenceId.png" alt="客户端序列号" loading="lazy"></figure>
<p>设计：</p>
<ul>
<li>
<p>数据传输中的大小尽量小用int，不用bigint，节省传输大小</p>
</li>
<li>
<p>只保证递增即可,在用户重新登录或者重连后可以进行日期重置，只保证单次</p>
</li>
<li>
<p>客户端发号器不需要像类似服务器端发号器那样集群部署，不需要考虑集群同步问题<br>
说明：上述生成器可以用18年[(2^29-1)/3600/24/365]左右，一秒内最多产生4个消息</p>
</li>
<li>
<p>优点：可以在断线重连和重装APP的情况下，18年之内是有序的</p>
</li>
<li>
<p>缺点：每秒只能发4个消息，限制太大，对于群发场景不合适</p>
</li>
<li>
<p>改进：使用long进行传输，年限扩展很久并且有序</p>
</li>
</ul>
<h5 id="方案二">方案二</h5>
<p>设计：</p>
<ul>
<li>
<p>每次重新建立链接后进行重置，将sequence_id（int表示）从0开始进行严格递增</p>
</li>
<li>
<p>客户端发送消息会带上唯一的递增sequence_id，同一条消息重复投递的sequence_id是一样的</p>
</li>
<li>
<p>后端存储每个用户的sequence_id，当sequence_id归0，用户的epoch年代加1存储入库，单聊场景下转发给接收者时候，接收者按照sequence_id和epoch来进行排序</p>
</li>
<li>
<p>优点：可以在断线重连和重装APP的情况下，接收者可以按照发送者发送时序来显示，并且对发送消息的速率没限制</p>
</li>
</ul>
<h4 id="21-lsb设计与优化">2.1 LSB设计与优化：</h4>
<h5 id="210-lsb设计">2.1.0 LSB设计</h5>
<ol>
<li>接入层的高可用、负载均衡、扩展性全部在这里面做</li>
<li>客户端通过LSB，来获取gate IP地址，通过IP直连，目的是
<ul>
<li>灵活的负载均衡策略 可根据最少连接数来分配IP</li>
<li>做灰度策略来分配IP</li>
<li>AppId业务隔离策略 不同业务连接不同的gate，防止相互影响</li>
<li>单聊和群聊的im接入层通道分开</li>
</ul>
</li>
</ol>
<h5 id="211-lsb优化">2.1.1 LSB优化</h5>
<p>问题背景：当某个实例重启后，该实例的连接断开后，客户端会发起重连，重连就大概率转移其他实例上，导致最近启动的实例连接数较少，最早启动的实例连接数较多<br>
解决方法：</p>
<ol>
<li>客户端会发起重连，跟服务器申请重连的新的服务器IP，系统提供合适的算法来平摊gate层的压力，防止雪崩效应。</li>
<li>gate层定时上报本机的元数据信息以及连接数信息，提供给LSB中心，LSB根据最少连接数负载均衡实现，来计算一个节点供连接。</li>
</ol>
<h4 id="22-gate设计">2.2 GATE设计：</h4>
<p>GATE层网关有以下特性：</p>
<ol>
<li>任何一个gate网关断掉，用户端检测到以后重新连接LSB服务获取另一个gate网关IP，拿到IP重新进行长连接通信。对整体服务可靠性基本没有影响。</li>
<li>gate可以无状态的横向部署，来扩展接入层的接入能力</li>
<li>根据协议分类将入口请求打到不同的网关上去，HTTP网关接收HTTP请求，TCP网关接收tcp长连接请求</li>
<li>长连接网关，提供各种监控功能，比如网关执行线程数、队列任务数、ByteBuf使用堆内存数、堆外内存数、消息上行和下行的数量以及时间</li>
</ol>
<h4 id="23-logic和路由sdk设计">2.3 LOGIC和路由SDK设计：</h4>
<ol>
<li>
<p>logic按照分布式微服务的拆分思想进行拆分，拆分为多个模块，集群部署：</p>
<ul>
<li>消息服务</li>
<li>红包服务</li>
<li>其他服务</li>
</ul>
</li>
<li>
<p>logic消息服务集成路由客户端SDK，SDK职责：</p>
<ul>
<li>负责和网关底层通信交互</li>
<li>负责网关服务寻址</li>
<li>负责存储uid和gate层机器ID关系（有状态：多级缓存避免和中间件多次交互。无状态：在业务初期可以不用存）</li>
<li>配合网关负责路由信息一致性保证
<ul>
<li>如果路由状态和channel通道不一致，比如有路由状态，没有channel通道（已关闭）那么，就会走离线消息流出，并且清除路由信息</li>
<li>动态重启gate，会及时清理路由信息</li>
</ul>
</li>
</ul>
</li>
<li>
<p>SDK和网关底层通信设计：<br>
<img src="https://zhangyaoo.github.io/post-images/gate_sdk.png" alt="交互设计图" loading="lazy"></p>
<ul>
<li>网关层到服务层，只需要单向传输发请求，网关层不需要关心调用的结果。而客户端想要的ack或者notify请求是由SDK发送数据到网关层，SDK也不需要关心调用的结果，最后网关层只转发数据，不做额外的逻辑处理</li>
<li>SDK和所有的网关进行长连接，当发送信息给客户端时，根据路由寻址信息，即可通过长连接推送信息</li>
</ul>
</li>
</ol>
<h3 id="3-协议设计">3. 协议设计</h3>
<h4 id="30-目标">3.0 目标</h4>
<ol>
<li>高性能：协议设计紧凑，保证数据包小，并且序列化性能好</li>
<li>可扩展性：针对后续业务发展，可以自由的自定义协议，无需较大改动协议结构</li>
</ol>
<h4 id="31-设计">3.1 设计</h4>
<p>IM协议采用二进制定长包头和变长包体来实现客户端和服务端的通信，并且采用谷歌protobuf序列化协议，设计如下：</p>
<figure data-type="image" tabindex="2"><img src="https://zhangyaoo.github.io/post-images/IM-protocol.png" alt="IM协议设计图" loading="lazy"></figure>
<p>各个字段如下解释：</p>
<ul>
<li>headData：头部标识，协议头标识，用作粘包半包处理。4个字节</li>
<li>version：客户端版本。4个字节</li>
<li>cmd：业务命令，比如心跳、推送、单聊、群聊。1个字节</li>
<li>msgType：消息通知类型 request response notify。1个字节</li>
<li>logId：调试性日志，追溯一个请求的全路径。4个字节</li>
<li>sequenceId：序列号，可以用作异步处理。4个字节</li>
<li>dataLength：数据体的长度。4个字节</li>
<li>data：数据</li>
</ul>
<h4 id="32-实践">3.2 实践</h4>
<ol>
<li>针对数据data，<strong>网关gate层不做反序列化，反序列化步骤在service做</strong>，避免重复序列化和反序列化导致的性能损失</li>
<li>网关层不做业务逻辑处理，只做消息转发和推送，减少网关层的复杂度</li>
</ol>
<h3 id="4-安全管理">4. 安全管理</h3>
<ol>
<li>为防止消息传输过程中不被截获、篡改、伪造，采用TLS传输层加密协议</li>
<li>私有化协议天然具备一定的防窃取和防篡改的能力，相对于使用JSON、XML、HTML等明文传输系统，被第三方截获后在内容破解上相对成本更高，因此安全性上会更好一些</li>
<li>消息存储安全性:针对账号密码的存储安全可以通过“高强度单向散列算法”和“加盐”机制来提升加密密码可逆性；IM消息采用“端到端加密”方式来提供更加安全的消息传输保护。</li>
<li>安全层协议设计。基于动态密钥，借鉴类似SSL，不需要用证书来管理。</li>
</ol>
<h3 id="5-消息流转设计">5. 消息流转设计</h3>
<p>一个正常的消息流转需要如图所示的流程：<br>
<img src="https://zhangyaoo.github.io/post-images/IM-pic1.png" alt="IM核心流程图" loading="lazy"></p>
<ol>
<li>客户端A发送请求包R</li>
<li>server将消息存储到DB</li>
<li>存储成功后返回确认ack</li>
<li>server push消息给客户端B</li>
<li>客户端B收到消息后返回确认ack</li>
<li>server收到ack后更新消息的状态或者删除消息</li>
</ol>
<p>需要考虑的是，一个健壮的系统需要考虑各种异常情况，如丢消息，重复消息，消息时序问题</p>
<h4 id="50-消息可靠性如何保证-不丢消息">5.0 消息可靠性如何保证 不丢消息</h4>
<ol>
<li>应用层ACK</li>
<li>客户端需要超时与重传</li>
<li>服务端需要超时与重传，具体做法就是增加ack队列和定时器Timer</li>
<li>业务侧兜底保证，客户端拉消息通过一个本地的旧的序列号来拉取服务器的最新消息</li>
<li>为了保证消息必达，在线客户端还增加一个定时器，定时向服务端拉取消息，避免服务端向客户端发送拉取通知的包丢失导致客户端未及时拉取数据。</li>
</ol>
<h4 id="51-消息重复性如何保证-不重复">5.1 消息重复性如何保证 不重复</h4>
<ol>
<li>超时与重传机制将导致接收的client收到重复的消息，具体做法就是一份消息使用同一个消息ID进行去重处理。</li>
</ol>
<h4 id="52-消息顺序性如何保证-不乱序">5.2 消息顺序性如何保证 不乱序</h4>
<h5 id="520-消息乱序影响的因素">5.2.0 消息乱序影响的因素</h5>
<ol>
<li>时钟不一致，分布式环境下每个机器的时间可能是不一致的</li>
<li>多发送方和多接收方，这种情况下，无法保先发的消息被先收到</li>
<li>网络传输和多线程，网络传输不稳定的话可能导致包在数据传输过程中有的慢有的快。多线程也可能是会导致时序不一致影响的因素</li>
</ol>
<p>以上，如果保持绝对的实现，那么只能是一个发送方，一个接收方，一个线程阻塞式通讯来实现。那么性能会降低。</p>
<h5 id="521-如何保证时序">5.2.1 如何保证时序</h5>
<ol>
<li>
<p>单聊：通过发送方的绝对时序seq，来作为接收方的展现时序seq。</p>
<ul>
<li>实现方式：可以通过时间戳或者本地序列号方式来实现</li>
<li>缺点：本地时间戳不准确或者本地序列号在意外情况下可能会清0，都会导致发送方的绝对时序不准确</li>
</ul>
</li>
<li>
<p>群聊：因为发送方多点发送时序不一致，所以通过服务器的单点做序列化，也就是通过ID递增发号器服务来生成seq，接收方通过seq来进行展现时序。</p>
<ul>
<li>实现方式：通过服务端统一生成唯一趋势递增消息ID来实现或者通过redis的递增incr来实现</li>
<li>缺点：redis的递增incr来实现，redis取号都是从主取的，会有性能瓶颈。ID递增发号器服务是集群部署，可能不同发号服务上的集群时间戳不同，可能会导致后到的消息seq还小。</li>
</ul>
</li>
<li>
<p>群聊时序的优化：按照上面的群聊处理，业务上按照道理只需要保证单个群的时序，不需要保证所有群的绝对时序，所以解决思路就是<strong>同一个群的消息落到同一个发号service</strong>上面，消息seq通过service本地生成即可。</p>
</li>
</ol>
<h5 id="522-客户端如何保证顺序">5.2.2 客户端如何保证顺序</h5>
<ol>
<li>
<p>为什么要保证顺序？</p>
<ul>
<li>消息即使按照顺序到达服务器端，也会可能出现：不同消息到达接收端后，可能会出现“先产生的消息后到”“后产生的消息先到”等问题。所以客户端需要进行兜底的流量整形机制</li>
</ul>
</li>
<li>
<p>如何保证顺序？</p>
<ul>
<li>接收方收到消息后进行判定，如果当前消息序号大于前一条消息的序号就将当前消息追加在会话里</li>
<li>否则继续往前查找倒数第二条、第三条等消息，一直查找到恰好小于当前推送消息的那条消息，然后插入在其后展示。</li>
</ul>
</li>
</ol>
<h3 id="6-消息通知设计">6 消息通知设计</h3>
<p><strong>整体消息推送和拉取的时序图如下：</strong><br>
<img src="https://zhangyaoo.github.io/post-images/msg-pull-push-model.png" alt="IM消息推拉模型" loading="lazy"></p>
<h4 id="60-消息拉取方式的选择">6.0 消息拉取方式的选择</h4>
<p>本项目是进行推拉结合来进行服务器端消息的推送和客户端的拉取，我们知道单pull和单push有以下缺点：</p>
<p>单pull：</p>
<ul>
<li>pull要考虑到消息的实时性，不知道消息何时送达</li>
<li>pull要考虑到哪些好友和群收到了消息，要循环每个群和好友拿到消息列表，读扩散</li>
</ul>
<p>单push：</p>
<ul>
<li>push实时性高，只要将消息推送给接收者就ok，但是会集中消耗服务器资源。并且再群聊非常多，聊天频率非常高的情况下，会增加客户端和服务端的网络交互次数</li>
</ul>
<p>推拉结合：</p>
<ul>
<li>推拉结合的方式能够分摊服务端的压力,能保证时效性，又能保证性能</li>
<li>具体做法就是有新消息时候，推送哪个好友或者哪个群有新消息，以及新消息的数量或者最新消息ID，客户端按需根据自身数据进行拉取</li>
</ul>
<h4 id="61-推拉隔离设计">6.1 推拉隔离设计</h4>
<ol>
<li>为什么做隔离
<ul>
<li>如果客户端一边正在拉取数据，一边有新的增量消息push过来</li>
</ul>
</li>
<li>如何做隔离
<ul>
<li>本地设置一个全局的状态，当客户端拉取完离线消息后设置状态为1（表示离线消息拉取完毕）。当客户端收到拉取实时消息，会启用一个轮询监听这个状态，状态为1后，再去向服务器拉取消息。</li>
<li>如果是push消息过来（不是主动拉取），那么会先将消息存储到本地的消息队列中，等待客户端上一次拉取数据完毕，然后将数据进行合并即可</li>
</ul>
</li>
</ol>
<h3 id="7-消息id生成设计">7 消息ID生成设计</h3>
<h5 id="70-设计">7.0 设计</h5>
<p>实际业务的情况【只做参考，实际可以根据公司业务线来调整】</p>
<ol>
<li>单机高峰并发量小于1W，预计未来5年单机高峰并发量小于10W</li>
<li>有2个机房，预计未来5年机房数量小于4个 每个机房机器数小于150台</li>
<li>目前只有单聊和群聊两个业务线，后续可以扩展为系统消息、聊天室、客服等业务线，最多8个业务线</li>
</ol>
<p>根据以上业务情况，来设计分布式ID：<br>
<img src="https://zhangyaoo.github.io/post-images/server-id.jpg" alt="IM服务端分布式ID设计" loading="lazy"></p>
<h5 id="71-优点">7.1 优点</h5>
<ul>
<li>不同机房不同机器不同业务线内生成的ID互不相同</li>
<li>每个机器的每毫秒内生成的ID不同</li>
<li>预留两位留作扩展位</li>
</ul>
<h5 id="72-缺点">7.2 缺点：</h5>
<p>当并发度不高的时候，时间跨毫秒的消息，区分不出来消息的先后顺序。因为时间跨毫秒的消息生成的ID后面的最后一位都是0，后续如果按照消息ID维度进行分库分表，会导致数据倾斜</p>
<h5 id="73-两种解决方案">7.3 两种解决方案：</h5>
<ol>
<li>方案一：去掉snowflake最后8位，然后对剩余的位进行取模</li>
<li>方案二：不同毫秒的计数，每次不是归0，而是归为随机数，相比方案一，比较简单实用</li>
</ol>
<h3 id="8-消息未读数设计">8 消息未读数设计</h3>
<h4 id="80-实现">8.0 实现</h4>
<ol>
<li>每发一个消息，消息接收者的会话未读数+1，并且接收者所有未读数+1</li>
<li>消息接收者返回消息接收确认ack后，消息未读数会-1</li>
<li>消息接收者的未读数+1，服务端就会推算有多少条未读数的通知</li>
</ol>
<h4 id="81-分布式锁保证总未读数和会话未读数一致">8.1 分布式锁保证总未读数和会话未读数一致</h4>
<ol>
<li>不一致原因：当总未读数增加，这个时候客户端来了请求将未知数置0，然后再增加会话未读数，那么会导致不一致</li>
<li>保证：为了保证总未读数和会话未读数原子性，需要用分布式锁来保证</li>
</ol>
<h4 id="82-群聊消息未读数难点和优化">8.2 群聊消息未读数难点和优化</h4>
<ol>
<li>
<p>难点</p>
<ul>
<li>一个群聊每秒几百的并发聊天，比如消息未读数，相当于每秒W级别的写入redis，即便redis做了集群数据分片+主从，但是写入还是单节点，会有写入瓶颈</li>
</ul>
</li>
<li>
<p>优化</p>
</li>
</ol>
<ul>
<li>群ID分组或者用户ID分组，批量写入，写入的两种方式
<ul>
<li>定时flush</li>
<li>满多少消息进行flush</li>
</ul>
</li>
</ul>
<h3 id="9-网关设计">9. 网关设计</h3>
<ul>
<li>接入层网关和应用层网关不同地方
<ul>
<li>接入层网关需要有接收通知包或者下行接收数据的端口，并且需要另外开启线程池。应用层网关不需要开端口，并且不需要开启线程池。</li>
<li>接入层网关需要保持长连接，接入层网关需要本地缓存channel映射关系。应用层网关无状态不需要保存。</li>
</ul>
</li>
</ul>
<h4 id="91-接入层网关设计">9.1 接入层网关设计</h4>
<h5 id="910-目标">9.1.0 目标：</h5>
<ol>
<li>网关的线程池实现1+8+4+1，减少线程切换</li>
<li>集中实现长连接管理和推送能力</li>
<li>与业务服务器解耦，集群部署缩容扩容以及重启升级不相互影响</li>
<li>长连接的监控与报警能力</li>
<li>客户端重连指令一键实现</li>
</ol>
<h5 id="911-技术点">9.1.1 技术点：</h5>
<ul>
<li>支持自定义协议以及序列化</li>
<li>支持websocket协议</li>
<li>通道连接自定义保活以及心跳检测</li>
<li>本地缓存channel</li>
<li>责任链</li>
<li>服务调用完全异步</li>
<li>泛化调用</li>
<li>转发通知包或者Push包</li>
<li>容错网关down机处理</li>
</ul>
<h5 id="912-设计方案">9.1.2 设计方案：</h5>
<p>一个Notify包的数据经网关的线程模型图：<br>
<img src="https://zhangyaoo.github.io/post-images/TCP-Gate-ThreadModel.png" alt="TCP网关线程模型" loading="lazy"></p>
<h4 id="92-应用层api网关设计">9.2 应用层API网关设计</h4>
<h5 id="920-目标">9.2.0 目标：</h5>
<ol>
<li>基于版本的自动发现以及灰度/扩容 ，不需要关注IP</li>
<li>网关的线程池实现1+8+1，减少线程切换</li>
<li>支持协议转换实现多个协议转换，基于SPI来实现</li>
<li>与业务服务器解耦，集群部署缩容扩容以及重启升级不相互影响</li>
<li>接口错误信息统计和RT时间的监控和报警能力</li>
<li>UI界面实现路由算法，服务接口版本管理，灰度策略管理以及接口和服务信息展示能力</li>
<li>基于OpenAPI提供接口级别的自动生成文档的功能</li>
</ol>
<h5 id="921-技术点">9.2.1 技术点：</h5>
<ul>
<li>Http2.0</li>
<li>channel连接池复用</li>
<li>Netty http 服务端编解码</li>
<li>责任链</li>
<li>服务调用完全异步</li>
<li>全链路超时机制</li>
<li>泛化调用</li>
</ul>
<h5 id="922-设计方案">9.2.2 设计方案：</h5>
<p>一个请求包的数据经网关的架构图：<br>
<img src="https://zhangyaoo.github.io/post-images/HTTP-gate.png" alt="网关的架构图" loading="lazy"></p>
<h3 id="10-高并发-高可用设计">10. 高并发、高可用设计</h3>
<h4 id="100-高并发设计">10.0 高并发设计</h4>
<h5 id="1000-架构优化">10.0.0 架构优化</h5>
<ul>
<li>水平扩展：各个模块无状态部署</li>
<li>线程模型：每个服务底层线程模型遵从Netty主从reactor模型</li>
<li>多层缓存：Gate层二级缓存，Redis一级缓存</li>
<li>长连接：客户端长连接保持，避免频繁创建连接消耗</li>
</ul>
<h5 id="1001-万人群聊优化">10.0.1 万人群聊优化</h5>
<ol>
<li>
<p>难点</p>
<ul>
<li>消息扇出大，比如每秒群聊有50条消息，群聊2000人，那么光一个群对系统并发就有10W的消息扇出</li>
</ul>
</li>
<li>
<p>优化</p>
<ul>
<li>批量ACK：每条群消息都ACK，会给服务器造成巨大的冲击，为了减少ACK请求量，参考TCP的Delay ACK机制，在接收方层面进行批量ACK。</li>
<li>群消息和成员批量加载以及懒加载：在真正进入一个群时才实时拉取群友的数据</li>
<li>群离线消息过多：群消息分页拉取,第二次拉取请求作为第一次拉取请求的ack</li>
<li>对于消息未读数场景，每个用户维护一个全局的未读数和每个会话的未读数，当群聊非常大时，未读资源变更的QPS非常大。这个时候应用层对未读数进行缓存，批量写+定时写来保证未读计数的写入性能</li>
<li>路由信息存入redis会有写入和读取的性能瓶颈，每条消息在发出的时候会查路由信息来发送对应的gate接入层，比如有10个群，每个群1W，那么1s100条消息，那么1000W的查询会打满redis，即使redis做了集群。优化的思路就是将集中的路由信息分散到msg层 JVM本地内存中，然后做Route可用，避免单点故障。</li>
<li>存储的优化，扩散写写入并发量巨大，另一方面也存在存储浪费，一般优化成扩散读的方式存储</li>
<li>消息路由到相同接入层机器进行合并请求减少网络包传输</li>
</ul>
</li>
</ol>
<h5 id="1002-代码优化">10.0.2 代码优化</h5>
<ul>
<li>本地会话信息由一个hashmap保持，导致锁机制严重，按照用户标识进行hash,讲会话信息存在多个map中，减少锁竞争</li>
<li>利用双buffer机制，避免未读计数写入阻塞</li>
</ul>
<h5 id="1003-推拉结合优化合并">10.0.3 推拉结合优化合并</h5>
<ol>
<li>背景：消息下发到群聊服务后，需要发送拉取通知给接收者，具体逻辑是群聊服务同步消息到路由层，路由层发送消息给接收者，接收者再来拉取消息。</li>
<li>问题：如果消息连续发送或者对同一个接收者连续发送消息频率过高，会有许多的通知消息发送给路由层，消息量过大，可能会导致logic线程堆积，请求路由层阻塞。</li>
<li>解决：发送者发送消息到逻辑层持久化后，将通知消息先存放一个队列中，相同的接收者接收消息通知消息后，更新相应的最新消息通知时间，然后轮训线程会轮训队列，将多个消息会合并为一个通知拉取发送至路由层，降低了客户端与服务端的网络消耗和服务器内部网络消耗。</li>
<li>好处：保证同一时刻，下发线程一轮只会向同一用户发送一个通知拉取，一轮的时间可以自行控制<br>
<img src="https://zhangyaoo.github.io/post-images/notifymerge.png" alt="客户端序列号" loading="lazy"></li>
</ol>
<h4 id="101-高可用设计">10.1 高可用设计</h4>
<h5 id="1010-心跳设计">10.1.0 心跳设计</h5>
<ol>
<li>服务端检测到某个客户端迟迟没有心跳过来可以主动关闭通道，让它下线，并且清除在线信息和路由信息；</li>
<li>客户端检测到某个服务端迟迟没有响应心跳也能重连获取一个新的连接。</li>
<li>智能心跳策略，比如正在发包的时候，不需要发送心跳。等待发包完毕后在开启心跳。并且自适应心跳策略调整。</li>
</ol>
<h5 id="1011-系统稳定性设计">10.1.1 系统稳定性设计</h5>
<ol>
<li>
<p>背景：高峰期系统压力大，偶发的网络波动或者机器过载，都有可能导致大量的系统失败。加上IM系统要求实时性，不能用异步处理实时发过来的消息。所以有了柔性保护机制防止雪崩</p>
</li>
<li>
<p>柔性保护机制开启判断指标，当每个指标不在平均范围内的时候就开启</p>
<ul>
<li>每条消息的ack时间 RT时间</li>
<li>同时在线人数以及同时发消息的人数</li>
<li>每台机器的负载CPU和内存和网络IO和磁盘IO以及GC参数</li>
</ul>
</li>
<li>
<p>当开启了柔性保护机制，那么会返回失败，用户端体验不友好，如何优化</p>
<ul>
<li>当开启了柔性保护机制，逻辑层hold住多余的请求，返回前端成功，不显示发送失败，后端异步重试，直至成功；</li>
<li>为了避免重试加剧系统过载，指数时间延迟重试</li>
</ul>
</li>
</ol>
<h5 id="1012-异常场景设计">10.1.2 异常场景设计</h5>
<ol>
<li>
<p>gate层重启升级或者意外down机有以下问题：</p>
<ul>
<li>客户端和gate意外丢失长连接，导致 客户端在发送消息的时候导致消息超时等待以及客户端重试等无意义操作</li>
<li>发送给客户端的消息，从Msg消息层转发给gate的消息丢失，导致消息超时等待以及重试。</li>
</ul>
</li>
<li>
<p>解决方案如下：</p>
<ul>
<li>重启升级时候，向客户端发送重新连接指令，让客户端重新请求LSB获取IP直连。</li>
<li>当gate层down机异常停止时候，增加hook钩子，向客户端发送重新连接指令。</li>
<li>额外增加hook，向Msg消息层发送请求清空路由消息和在线状态，并且清除redis的路由信息。</li>
</ul>
</li>
</ol>
<h5 id="1013-redis宕机高可用设计">10.1.3 Redis宕机高可用设计</h5>
<ol>
<li>
<p>Redis作用背景</p>
<ul>
<li>当用户链接上网关后，网关会将用户的userId和机器信息存入redis，用作这个user接收消息时候，消息的路由</li>
<li>消息服务在发消息给user时候，会查询Redis的路由信息，用来发送消息给哪个一个网关</li>
</ul>
</li>
<li>
<p>如果Redis宕机，会造成下面结果</p>
<ul>
<li>消息中转不过去，所有的用户可以发送消息，但是都接收不了消息</li>
<li>如果有在线机制，那么系统都认为是离线状态，会走手机消息通道推送</li>
</ul>
</li>
<li>
<p>Redis宕机兜底处理策略</p>
<ul>
<li>消息服务定时任务同步路由信息到本地缓存，如果redis挂了，从本地缓存拿消息</li>
<li>网关服务在收到用户侧的上线和下线后，会同步广播本地的路由信息给各个消息服务，消息服务接收后更新本地环境数据</li>
<li>网络交互次数多，以及消息服务多，可以用批量或者定时的方式同步广播路由消息给各个消息服务</li>
</ul>
</li>
</ol>
<h3 id="11-核心表结构设计">11. 核心表结构设计</h3>
<p>核心设计点</p>
<ol>
<li>群消息只存储一份，用户不需要为每个消息单独存一份。用户也无需去删除群消息。</li>
<li>对于在线的用户，收到群消息后，修改这个last_ack_msg_id。</li>
<li>对于离线用户，用户上线后，对比最新的消息ID和last_ack_msg_id，来进行拉取(参考Kafka的消费者模型)</li>
<li>对应单聊，需要记录消息的送达状态，以便在异常情况下来做重试处理</li>
</ol>
<h4 id="群用户消息表-t_group_user_msg">群用户消息表 t_group_user_msg</h4>
<table>
<thead>
<tr>
<th>字段</th>
<th>类型</th>
<th>描述</th>
</tr>
</thead>
<tbody>
<tr>
<td>id</td>
<td>int</td>
<td>自增ID</td>
</tr>
<tr>
<td>group_id</td>
<td>int</td>
<td>群ID</td>
</tr>
<tr>
<td>user_id</td>
<td>bigint</td>
<td>用户ID</td>
</tr>
<tr>
<td>last_ack_msg_id</td>
<td>bigint</td>
<td>最后一次ack的消息ID</td>
</tr>
<tr>
<td>user_device_type</td>
<td>tinyint</td>
<td>用户设备类型</td>
</tr>
<tr>
<td>is_deleted</td>
<td>tinyint</td>
<td>是否删除,根据这个字段后续可以做冷备归档</td>
</tr>
</tbody>
</table>
<h4 id="群消息表-t_group_msg">群消息表 t_group_msg</h4>
<table>
<thead>
<tr>
<th>字段</th>
<th>类型</th>
<th>描述</th>
</tr>
</thead>
<tbody>
<tr>
<td>id</td>
<td>int</td>
<td>自增ID</td>
</tr>
<tr>
<td>msg_id</td>
<td>bigint</td>
<td>消息ID</td>
</tr>
<tr>
<td>group_id</td>
<td>int</td>
<td>群ID</td>
</tr>
<tr>
<td>sender_id</td>
<td>bigint</td>
<td>发送方ID</td>
</tr>
<tr>
<td>msg_type</td>
<td>int</td>
<td>消息类型</td>
</tr>
<tr>
<td>msg_content</td>
<td>varchar</td>
<td>消息内容</td>
</tr>
</tbody>
</table>
<h3 id="12-核心业务流程">12 核心业务流程</h3>
<h4 id="120-用户a发消息给用户b-单聊">12.0 用户A发消息给用户B 【单聊】</h4>
<ul>
<li>A打包数据发送给服务端，服务端接收消息后，根据接收消息的sequence_id来进行客户端发送消息的去重，并且生成递增的消息ID，将发送的信息和ID打包一块入库，入库成功后返回ACK，ACK包带上服务端生成的消息ID</li>
<li>服务端检测接收用户B是否在线，在线直接推送给用户B</li>
<li>如果没有本地消息ID则存入，并且返回接入层ACK信息；如果有则拿本地sequence_id和推送过来的sequence_id大小对比，并且去重，进行展现时序进行排序展示，并且记录最新一条消息ID。最后返回接入层ack</li>
<li>服务端接收ACK后，将消息标为已送达</li>
<li>如果用户B不在线,首先将消息存入库中，然后直接通过手机通知来告知客户新消息到来</li>
<li>用户B上线后，拿本地最新的消息ID，去服务端拉取所有好友发送给B的消息，考虑到一次拉取所有消息数据量大，通过channel通道来进行分页拉取，将上一次拉取消息的最大的ID，作为请求参数，来请求最新一页的比ID大的数据。</li>
</ul>
<h4 id="121-用户a发消息给群g-群聊">12.1 用户A发消息给群G 【群聊】</h4>
<ul>
<li>登录，TCP连接，token校验，名词检查，sequence_id去重，生成递增的消息ID，群消息入库成功返回发送方ACK</li>
<li>查询群G所有的成员，然后去redis中央存储中找在线状态。离线和在线成员分不同的方式处理</li>
<li>在线成员：并行发送拉取通知，等待在线成员过来拉取，发送拉取通知包如丢失会有兜底机制</li>
<li>在线成员过来拉取，会带上这个群标识和上一次拉取群的最小消息ID，服务端会找比这个消息ID大的所有的数据返回给客户端，等待客户端ACK。一段时间没ack继续推送。如果重试几次后没有回ack，那么关闭连接和清除ack等待队列消息</li>
<li>客户端会更新本地的最新的消息ID，然后进行ack回包。服务端收到ack后会更新群成员的最新的消息ID</li>
<li>离线成员：发送手机通知栏通知。离线成员上线后，拿本地最新的消息ID，去服务端拉取群G发送给A的消息，通过channel通道来进行分页拉取，每一次请求，会将上一次拉取消息的最大的ID，作为请求参数来拉取消息，这里相当于第二次拉取请求包是作为第一次拉取的ack包。</li>
<li>分页的情况下，客户端在收到上一页请求的的数据后更新本地的最新的消息ID后，再请求下一页并且带上消息ID。上一页请求的的数据可以当作为ack来返回服务端，避免网络多次交互。服务端收到ack后会更新群成员的最新的消息ID</li>
</ul>
<h3 id="13-红包设计">13 红包设计</h3>
<h4 id="131-抢红包的大致核心逻辑">13.1 抢红包的大致核心逻辑</h4>
<ol>
<li>银行快捷支付，保证账户余额和发送红包逻辑的一致性</li>
<li>发送红包后，首先计算好红包的个数，个数确定好后，确定好每个红包的金额，存入存储层【这里可以是redis的List或者是队列】方便后续每个人来取</li>
<li>生成一个24小时的延迟任务，检测红包是否还有钱方便退回</li>
<li>每个红包的金额需要保证每个红包的的抢金额概率是一致的，算法需要考量</li>
<li>存入数据库表中后，服务器通过长连接，给群里notify红包消息,供群成员抢红包</li>
<li>群成员并发抢红包，在第二步中会将每个红包的金额放入一个队列或者其他存储中，群成员实际是来竞争去队列中的红包金额。兜底机制：如果redis挂了，可以重新生成红包信息到数据库中</li>
<li>取成功后，需要保证红包剩余金额、新插入的红包流水数据、队列中的红包数据以及群成员的余额账户金额一致性。</li>
<li>这里还需要保证一个用户只能领取一次，并且保持幂等</li>
</ol>
<h2 id="三-qa">三、Q&amp;A</h2>
<ol start="0">
<li>
<p>Q：相比传统HTTP请求的业务系统，IM业务系统的有哪些不一样的设计难点？</p>
<ul>
<li>在线状态维护。相比于HTTP请求的业务系统，接入层有状态，必须维持心跳和会话状态，加大了系统设计复杂度。</li>
<li>请求通信模型不一样。相比于HTTP请求一个request等待一个response通信模型，IM系统则是一个数据包在全双工长连接通道双传输，客户端和服务端消息交互的信令数据包设计复杂。</li>
</ul>
</li>
<li>
<p>Q：对于单聊和群聊的实时性消息，是否需要MQ来作为通信的中间件来代替rpc？</p>
<p>A：MQ作为解耦可以有以下好处：</p>
<ul>
<li>易扩展，gate层到logic层无需路由，logic层多个有新的业务时候，只需要监听新的topic即可</li>
<li>解耦，gate层到logic层解耦，不会有依赖关系</li>
<li>节省端口资源，gate层无需再开启新的端口接收logic的请求，而且直接监听MQ消息即可</li>
</ul>
<p>但是缺点也有：</p>
<ul>
<li>网络通信多一次网络通信，增加RT的时间，消息实时性对于IM即使通信的场景是非常注重的一个点</li>
<li>MQ的稳定性，不管任何系统只要引入中间件都会有稳定性问题，需要考虑MQ不可用或者丢失数据的情况</li>
<li>需要考虑到运维的成本</li>
<li>当用消息中间代替路由层的时候，gate层需要广播消费消息，这个时候gate层会接收大部分的无效消息，因为这个消息的接收者channel不在本机维护的session中</li>
</ul>
<p>综上，是否考虑使用MQ需要架构师去考量，比如考虑业务是否允许、或者系统的流量、或者高可用设计等等影响因素。本项目基于使用成本、耦合成本和运维成本考虑，采用Netty作为底层自定义通信方案来实现，也能同样实现层级调用。</p>
</li>
<li>
<p>Q：为什么接入层用LSB返回的IP来做接入呢？</p>
<p>A：可以有以下好处：1、灵活的负载均衡策略 可根据最少连接数来分配IP；2、做灰度策略来分配IP；3、AppId业务隔离策略 不同业务连接不同的gate，防止相互影响</p>
</li>
<li>
<p>Q：为什么应用层心跳对连接进行健康检查？</p>
<p>A：因为TCP Keepalive状态无法反应应用层状态问题，如进程阻塞、死锁、TCP缓冲区满等情况；并且要注意心跳的频率，频率小则可能及时感知不到应用情况，频率大可能有一定的性能开销。</p>
</li>
<li>
<p>Q：MQ的使用场景？</p>
<p>A：IM消息是非常庞大的，比如说群聊相关业务、推送，对于一些业务上可以忍受的场景，尽量使用MQ来解耦和通信，来降低同步通讯的服务器压力。</p>
</li>
<li>
<p>Q：群消息存一份还是多份，读扩散还是写扩散？</p>
<p>A：存1份，读扩散。存多份下同一条消息存储了很多次，对磁盘和带宽造成了很大的浪费。可以在架构上和业务上进行优化，来实现读扩散。</p>
</li>
<li>
<p>Q：消息ID为什么是趋势递增就可以，严格递增的不行吗？</p>
<p>A：严格递增会有单点性能瓶颈，比如MySQL auto increments；redis性能好但是没有业务语义，比如缺少时间因素，还可能会有数据丢失的风险，并且集群环境下写入ID也属于单点，属于集中式生成服务。小型IM可以根据业务场景需求直接使用redis的incr命令来实现IM消息唯一ID。本项目采用snowflake算法实现唯一趋势递增ID，即可实现IM消息中，时序性，重复性以及查找功能。</p>
</li>
<li>
<p>Q：gate层为什么需要开两个端口？</p>
<p>A：gate会接收客户端的连接请求（被动），需要外网监听端口；entry会主动给logic发请求（主动）；entry会接收服务端给它的通知请求（被动），需要内网监听端口。一个端口对内，一个端口对外。</p>
</li>
<li>
<p>Q：用户的路由信息，是维护在中央存储的redis中，还是维护在每个msg层内存中？</p>
<ul>
<li>维护在每个msg层内存中有状态：多级缓存避免和中间件多次交互, 并发高</li>
<li>维护在中央存储的redis中，msg层无状态，redis压力大，每次交互IO网络请求大<br>
业务初期为了减少复杂度，可以维护在Redis中</li>
</ul>
</li>
<li>
<p>Q：网关层和服务层以及msg层和网关层请求模型具体是怎样的？</p>
<ul>
<li>网关层到服务层，只需要单向传输发请求，网关层不需要关心调用的结果。而客户端想要的ack或者notify请求是由SDK发送数据到网关层，SDK也不需要关心调用的结果，最后网关层只转发数据，不做额外的逻辑处理。</li>
<li>SDK和所有的网关进行长连接，当发送信息给客户端时，根据路由寻址信息，即可通过长连接推送信息</li>
</ul>
</li>
<li>
<p>Q：本地写数据成功，一定代表对端应用侧接收读取消息了吗？<br>
A：本地TCP写操作成功，但数据可能还在本地写缓冲区中、网络链路设备中、对端读缓冲区中，并不代表对端应用读取到了数据。</p>
</li>
<li>
<p>Q：为什么用netty做来做http网关, 而不用tomcat？</p>
<ul>
<li>netty对象池，内存池，高性能线程模型</li>
<li>netty堆外内存管理，减少GC压力，jvm管理的只是一个很小的DirectByteBuffer对象引用</li>
<li>tomcat读取数据和写入数据都需要从内核态缓冲copy到用户态的JVM中，多1次或者2次的拷贝会有性能影响</li>
</ul>
</li>
<li>
<p>Q：为什么消息入库后，对于在线状态的用户，单聊直接推送，群聊通知客户端来拉取，而不是直接推送消息给客户端（推拉结合）？<br>
A：在保证消息实时性的前提下，对于单聊，直接推送。对于群聊，由于群聊人数多，推送的话一份群消息会对群内所有的用户都产生一份推送的消息，推送量巨大。解决办法是按需拉取，当群消息有新消息时候发送时候，服务端主动推送新的消息数量，然后客户端分页按需拉取数据。</p>
</li>
<li>
<p>Q：为什么除了单聊 群聊 推送 离线拉取等实时性业务，其他的业务都走http协议？<br>
A：IM协议简单最好，如果让其他的业务请求混进IM协议中，会让其IM变的更复杂，比如查找离线消息记录拉取走http通道避免tcp 通道压力过大，影响即时消息下发效率。在比如上传图片和大文件，可以利用HTTP的断点上传和分段上传特性</p>
</li>
<li>
<p>Q：机集群机器要考虑到哪些优化？<br>
A：网络宽带；最大文件句柄；每个tcp的内存占用；Linux系统内核tcp参数优化配置；网络IO模型；网络网络协议解析效率；心跳频率；会话数据一致性保证；服务集群动态扩容缩容</p>
</li>
</ol>
<h2 id="四-contact">四、Contact</h2>
<ul>
<li>网站：zhangyaoo.github.io</li>
<li>微信：will_zhangyao</li>
</ul>
]]></content>
    </entry>
    <entry>
        <title type="html"><![CDATA[浅谈结构化思维]]></title>
        <id>https://zhangyaoo.github.io/post/jie-gou-hua-si-wei/</id>
        <link href="https://zhangyaoo.github.io/post/jie-gou-hua-si-wei/">
        </link>
        <updated>2021-07-23T03:54:14.000Z</updated>
        <content type="html"><![CDATA[<h3 id="what">what：</h3>
<p>是一种以无序到有序的整理信息和构建结构化的思维方式，目的是减少认知复杂度，是的更加被容易理解和记忆，表达清晰</p>
<h3 id="why">why:</h3>
<p>0213645879 和 0123456789，这两串数字哪个更容易被人记住。<br>
当然是按照顺序排列的数字串比杂乱无序排列的要更容易被记住。<br>
因为人类更容易记住结构化的信息。</p>
<h3 id="how">how：</h3>
<p><img src="https://zhangyaoo.github.io/post-images/1627012568883.png" alt="" loading="lazy"><br>
塔尖就是我们的中心思想或主题。塔身就是构成中心思考或者主题的各个分论点。而塔基则是支撑各个分论点的要素或论据</p>
<p>1、综上而下的结构化思维<br>
纵向是自上而下的层次的关系，下一层是上一层的解释和构成，上一层是下一层的总结和概括<br>
比如，先给结论后给原因，先目的后方法，先抽象后具体，先整体后部分<br>
2、从左往右的顺序思维，在同一个组内必须是同一个逻辑范畴，按照顺序来组织</p>
<h4 id="具体的步骤">具体的步骤：</h4>
<p>1、确定问题产生背景<br>
2、确定核心目标<br>
3、拆解核心目标<br>
4、继续分解，直到能够把问题解释清楚，形成方法论</p>
<h3 id="example">example</h3>
<h4 id="1-采购清单">1、采购清单</h4>
<figure data-type="image" tabindex="1"><img src="https://zhangyaoo.github.io/post-images/1627012578248.png" alt="" loading="lazy"></figure>
<h4 id="2-带团队">2、带团队</h4>
<figure data-type="image" tabindex="2"><img src="https://zhangyaoo.github.io/post-images/1627012581164.png" alt="" loading="lazy"></figure>
<h4 id="3-事情划分方法">3、事情划分方法</h4>
<figure data-type="image" tabindex="3"><img src="https://zhangyaoo.github.io/post-images/1627012584884.png" alt="" loading="lazy"></figure>
]]></content>
    </entry>
    <entry>
        <title type="html"><![CDATA[HikariDataSource核心源码分析]]></title>
        <id>https://zhangyaoo.github.io/post/hikaridatasource-he-xin-yuan-ma-fen-xi/</id>
        <link href="https://zhangyaoo.github.io/post/hikaridatasource-he-xin-yuan-ma-fen-xi/">
        </link>
        <updated>2021-02-24T03:31:24.000Z</updated>
        <content type="html"><![CDATA[<h2 id="一-前言">一、前言</h2>
<p>上一篇文章讲了不合理的连接池代码导致的内存泄露事件，详见这篇文章<a href="https://zhangyaoo.github.io/post/ji-yi-ci-duo-shu-ju-yuan-lu-you-zao-cheng-de-shu-ju-ku-lian-jie-nei-cun-xie-lu/">记一次多数据源路由造成的数据库连接泄露排查过程</a>。其中粗略的分析了HikariDataSource连接池的代码，并没有仔细分析。本篇文章带读者们一起去分析一波源码，看完本篇文章后，你可以<br>
1、对锁和高并发有一定理解以及其在连接池中的运用<br>
2、了解HikariDataSource业界性能最高连接池的原因<br>
3、可以对连接池的原理有大致的了解，可以尝试自己实现一个连接池</p>
<h2 id="二-源码分析">二、源码分析</h2>
<h3 id="20-关键代码类介绍">2.0 关键代码类介绍</h3>
<ol>
<li>HikariDataSource对象：Hikari中的核心类为HikariDataSource，实现了DataSource的getConnetion接口</li>
<li>HikariPool对象：HikariDataSource中有两个HikariPool对象,一个是fastPathPool是在HikariPool有参构造函数中创建, 如果没有创建fastPathPool,那么就会在getConnection方法时创建pool对象。</li>
<li>ConcurrentBag对象：连接池的真正实现，实现了<strong>高性能高并发的无锁设计</strong>，主要的方法有borrow 借,requite 归还,add 新增,remove 去除。</li>
<li>PoolEntry对象：对数据库connection对象进行包装，增加额外的属性，包括最后一次访问时间，是否丢弃，当前状态等等。HikariDataSource源码底层里面都是操作这个对象。</li>
</ol>
<h3 id="21-初始化以下所有代码只列出关键实现">2.1 初始化（以下所有代码只列出关键实现）</h3>
<p>初始化工作包括HikariDataSource初始化，HikariPool初始化，connectionBag初始化，一些线程池的初始化，最小连接数的初始化，以下逐一分析</p>
<pre><code class="language-java">public HikariDataSource(HikariConfig configuration)
{
  // 一个datasource有两个HikariPool成员变量，fastPathPool无参构造为null，用final修饰，pool有参构造，用volatile修饰
  // 因为volatile修饰的对象，需要从主内存读取，而且需要写入主内存等操作，所以最好在使用上用有参构造来构造HikariDataSource
  pool = fastPathPool = new HikariPool(this);
  // 连接池配置锁定无法修改
  this.seal();
}
// HikariPool初始化成员变量EntryCreator，创建PoolEntry的任务
private final PoolEntryCreator postFillPoolEntryCreator = new PoolEntryCreator(&quot;After adding &quot;);

public HikariPool(final HikariConfig config)
{
  // 初始化配置，根据配置生成datasource变量
  super(config);
  // 生成真正的连接池，后续的获取连接释放连接都是从这里面弄的
  this.connectionBag = new ConcurrentBag&lt;&gt;(this);
  // 测试数据库的连通性
  checkFailFast();
  // 增加连接的线程池
  this.addConnectionExecutor = createThreadPoolExecutor(addConnectionQueue, poolName + &quot; connection adder&quot;, threadFactory, new ThreadPoolExecutor.DiscardOldestPolicy());
  // 关闭连接的线程池
  this.closeConnectionExecutor = createThreadPoolExecutor(maxPoolSize, poolName + &quot; connection closer&quot;, threadFactory, new ThreadPoolExecutor.CallerRunsPolicy());
  // 初始化维持最小连接数任务
  this.houseKeeperTask = houseKeepingExecutorService.scheduleWithFixedDelay(new HouseKeeper(), 100L, housekeepingPeriodMs, MILLISECONDS);
}
</code></pre>
<p>重点是维持最小连接数任务，如下：</p>
<pre><code class="language-java">private final class HouseKeeper implements Runnable{
  public void run(){
     // Detect retrograde time, allowing +128ms as per NTP spec.
    if (plusMillis(now, 128) &lt; plusMillis(previous, housekeepingPeriodMs)) {
       previous = now;
       // 标为丢弃的连接关闭
       softEvictConnections();
       return;
    }
    if (idleTimeout &gt; 0L &amp;&amp; config.getMinimumIdle() &lt; config.getMaximumPoolSize()) {
       // 获取当前连接池中已经不是使用中的连接集合
       final List&lt;PoolEntry&gt; notInUse = connectionBag.values(STATE_NOT_IN_USE);
       int toRemove = notInUse.size() - config.getMinimumIdle();
       for (PoolEntry entry : notInUse) {
          // 如果PoolEntry的最后一次访问的时间超过了idleTimeout并且将这个PoolEntry的状态变为不可借状态STATE_RESERVED
          // STATE_RESERVED状态底层变更是CAS变更，用到的类是AtomicIntegerFieldUpdater，可以对指定类的指定 volatile int 字段进行原子更新
          if (toRemove &gt; 0 &amp;&amp; elapsedMillis(entry.lastAccessed, now) &gt; idleTimeout &amp;&amp; connectionBag.reserve(entry)) {
             // 关闭连接
             closeConnection(entry, &quot;(connection has passed idleTimeout)&quot;);
             toRemove--;
          }
       }
    }
    // 填充最小连接到minimum。 在初始化时候就填充连接，异步填充
    fillPool();
  }
}
// 填充连接
// 当没有达到最大连接数之前 或者 空闲连接数小于最小连接数时候 就异步提交创建poolEntryCreator任务
private synchronized void fillPool(){
  final int connectionsToAdd = Math.min(config.getMaximumPoolSize() - getTotalConnections(), config.getMinimumIdle() - getIdleConnections())
                               - addConnectionQueueReadOnlyView.size();
  for (int i = 0; i &lt; connectionsToAdd; i++) {
     addConnectionExecutor.submit((i &lt; connectionsToAdd - 1) ? poolEntryCreator : postFillPoolEntryCreator);
  }
}

// 关闭连接
void closeConnection(final PoolEntry poolEntry, final String closureReason){
    // 如果remove成功，将状态设置为STATE_REMOVED
	if (connectionBag.remove(poolEntry)) {
     final Connection connection = poolEntry.close();
     // 异步关闭
     closeConnectionExecutor.execute(() -&gt; {
        quietlyCloseConnection(connection, closureReason);
        if (poolState == POOL_NORMAL) {
           fillPool();
        }
     });
  }
}

</code></pre>
<p>以上大致逻辑就是，将被标为丢弃的连接关闭，将空闲超时的连接进行关闭，然后进行进连接填充连接，填充连接的逻辑就是增加poolEntryCreator任务,poolEntryCreator逻辑在后面分析。</p>
<h3 id="22-获取连接">2.2 获取连接</h3>
<p>获取连接是主要的实现逻辑，首先看HikariDataSource对象getConnnection方法</p>
<pre><code class="language-java">// 双重锁实现
public Connection getConnection(){
	HikariPool result = pool;
	if (result == null) {
	 synchronized (this) {
	    result = pool;
	    if (result == null) {
	       pool = result = new HikariPool(this);
	       // 锁定配置，不能热更新配置
	       this.seal();
	    }
	 }
	}
	return result.getConnection();
}
</code></pre>
<p>result.getConnection()就是HikariPool getConnection方法，这里面大致核心逻辑就是加锁在超时时间内获取poolEntry的connectionBag.borrow方法，重点着重borrow方法实现。</p>
<p>在讲之前，先介绍以下connectionBag的几个重要的成员变量</p>
<ol>
<li>final CopyOnWriteArrayList<T> sharedList：当前所有缓存的poolEntry连接，都在这个list内，CopyOnWriteArrayList写时复制，在读多写少的场景下性能更高，一般情况下连接池中的poolEntry连接不会增加或者关闭，读场景多。</li>
<li>final ThreadLocal&lt;List<Object>&gt; threadList ：当前线程缓存的本地poolEntry的list。朝生夕灭的线程，是无法有效利用本地线程缓存的，只有在线程池场景或者当前线程多次使用getConnetion获取connection方法进行增删改时候，才会有效的使用ThreadLocal。</li>
<li>final boolean weakThreadLocals：是否是弱引用，ThreadLocal可能会存在内存泄露的风险，当值为true时包装的poolEntry对象是弱引用，在内存不足时GC的时候会被回收，避免了出现内存泄露的问题。</li>
<li>final IBagStateListener listener：监听器，监听创建poolEntry的任务</li>
<li>final AtomicInteger waiters：当前正在等待获取连接的数量</li>
<li>final SynchronousQueue<T> handoffQueue：无存储元素的单个提供者和消费者通信队列，并且是公平模式。比如，是谁先来take操作，谁就会优先take成功，类似FIFO。</li>
<li>this.threadList = ThreadLocal.withInitial(() -&gt; new FastList&lt;&gt;(IConcurrentBagEntry.class, 16))：默认情况下会ThreadLocal value默认使用fastList来存储poolEntry，fastList是Hikari自己写一个不需要范围检查的一个List，而且它的remove方法是从后往前遍历删除的（和arrayList相反），刚好符合下面倒叙遍历获取poolEntry的逻辑</li>
</ol>
<pre><code class="language-java">public T borrow(long timeout, final TimeUnit timeUnit) throws InterruptedException
   {
      // Try the thread-local list first
      // 1、优先从本地线程缓存中获取poolEntry
      final List&lt;Object&gt; list = threadList.get();
      // 倒叙遍历，优先获取最近使用的poolEntry
      for (int i = list.size() - 1; i &gt;= 0; i--) {
         final Object entry = list.remove(i);
         // 开启弱引用就对value进行弱引用包装
         final T bagEntry = weakThreadLocals ? ((WeakReference&lt;T&gt;) entry).get() : (T) entry;
         // CAS成功就返回poolEntry
         if (bagEntry != null &amp;&amp; bagEntry.compareAndSet(STATE_NOT_IN_USE, STATE_IN_USE)) {
            return bagEntry;
         }
      }

      // Otherwise, scan the shared list ... then poll the handoff queue
      // 2、本地缓存没有，那么从所有缓存的poolEntry连接列表中获取
      final int waiting = waiters.incrementAndGet();
      try {
         for (T bagEntry : sharedList) {
            if (bagEntry.compareAndSet(STATE_NOT_IN_USE, STATE_IN_USE)) {
               // If we may have stolen another waiter's connection, request another bag add.
               // 如果等待的任务大于1，添加一个监听任务
               if (waiting &gt; 1) {
                  listener.addBagItem(waiting - 1);
               }
               return bagEntry;
            }
         }

         // 如果sharedList都在使用状态中，添加一个监听任务
         listener.addBagItem(waiting);

		 // 3、所有的连接正在被使用，超时等待其他poolEntry被归还通知handoffQueue
         timeout = timeUnit.toNanos(timeout);
         do {
            final long start = currentTime();
            // 从阻塞队列中获取bagEntry
            final T bagEntry = handoffQueue.poll(timeout, NANOSECONDS);
            if (bagEntry == null || bagEntry.compareAndSet(STATE_NOT_IN_USE, STATE_IN_USE)) {
               return bagEntry;
            }

            timeout -= elapsedNanos(start);
         } while (timeout &gt; 10_000);
         return null;
      }finally {
         waiters.decrementAndGet();
      }
   }
</code></pre>
<p>以上具体实现步骤</p>
<ol>
<li>优先从本地线程缓存中获取poolEntry</li>
<li>本地缓存没有，那么从所有缓存的poolEntry连接列表中获取</li>
<li>所有的连接正在被使用，增加一个监听任务，这个任务就是异步创建poolEntry，以便给此次阻塞的线程提供poolEntry</li>
<li>超时等待其他poolEntry被归还或者新建后 通知handoffQueue，以便获取poolEntry</li>
</ol>
<p>可以总结出，Hikari连接池最大限度上减少多线程锁竞争，提升连接池的性能。</p>
<p>然后看一下异步创建poolEntry poolEntryCreator的实现：</p>
<pre><code class="language-java">private final class PoolEntryCreator implements Callable&lt;Boolean&gt; {
  @Override
  public Boolean call()
  {
     // 只有特定条件下才创建PoolEntry
     while (poolState == POOL_NORMAL &amp;&amp; shouldCreateAnotherConnection()) {
        // 创建PoolEntry
        final PoolEntry poolEntry = createPoolEntry();
        if (poolEntry != null) {
           // 在连接池中增加PoolEntry
           connectionBag.add(poolEntry);
           return Boolean.TRUE;
        }
     }

     // Pool is suspended or shutdown or at max size
     return Boolean.FALSE;
  }

  // 1、总的连接数小于最大连接数 
  // 2、当前连接池中的等待获取连接的线程大于0  或者 连接池中的空闲连接小于最小连接池数
  // 满足所有上述条件后才创建poolEntry
  private synchronized boolean shouldCreateAnotherConnection() {
     return getTotalConnections() &lt; config.getMaximumPoolSize() &amp;&amp;
        (connectionBag.getWaitingThreadCount() &gt; 0 || getIdleConnections() &lt; config.getMinimumIdle());
  }
}

// 真正创建poolEntry的实现
private PoolEntry createPoolEntry(){
  try {
      // 创建poolEntry
     final PoolEntry poolEntry = newPoolEntry();

     final long maxLifetime = config.getMaxLifetime();
     if (maxLifetime &gt; 0) {
        // variance up to 2.5% of the maxlifetime
        final long variance = maxLifetime &gt; 10_000 ? ThreadLocalRandom.current().nextLong( maxLifetime / 40 ) : 0;
        final long lifetime = maxLifetime - variance;
        // 如果配置了maxlifetime，那么会给这一个连接增加一个延迟任务
        // 延迟任务主要就是将这个连接标记为Evict不可用
        poolEntry.setFutureEol(houseKeepingExecutorService.schedule(
           () -&gt; {
              if (softEvictConnection(poolEntry, &quot;(connection has passed maxLifetime)&quot;, false /* not owner */)) {
                 addBagItem(connectionBag.getWaitingThreadCount());
              }
           },
           lifetime, MILLISECONDS));
     }
     return poolEntry;
  }
  return null;
}
</code></pre>
<p>由上面createPoolEntry可以知道，HikariCP在使用时不会关闭连接。如果使用中的连接到达maxLifetime时它将被标记为驱逐，并且在下一次线程尝试借用它时将被驱逐，这也是Hikari连接池设计的一个核心精髓。</p>
<p>再来看一下connectionBag的add方法</p>
<pre><code class="language-java">public void add(final T bagEntry){
      // 在sharedList增加bagEntry
      sharedList.add(bagEntry);
      // spin until a thread takes it or none are waiting
      // 满足一下条件后，让出当前线程CPU时间片，让其他线程去工作
      // 1、当等待获取连接的线程大于0  2、当前的PoolEntry状态是没占用  3、没有其他线程去从队列中取任务
      while (waiters.get() &gt; 0 &amp;&amp; bagEntry.getState() == STATE_NOT_IN_USE &amp;&amp; !handoffQueue.offer(bagEntry)) {
         Thread.yield();
      }
   }
</code></pre>
<p>可以看到，新增的poolEntry会加入到sharedList所有的缓存连接中，并且要满足上述三个条件的时候会一直循环让出CPU时间片，让其他线程从无界队列中去取连接</p>
<h3 id="23-释放连接">2.3 释放连接</h3>
<p>Hikari实现了关闭连接Connection的方法，不是真正的关闭连接，而是归还到连接池当中，实现逻辑在ProxyConnection的close方法中，然后会调用poolEntry的recycle方法，最终会调用ConcurrentBag的requite方法，我们着重分析这个方法：</p>
<pre><code class="language-java">// 此方法会将借来的对象返回到ConcurrentBag中。如果不归还会导致内存泄露
public void requite(final T bagEntry){
  // 设置为未使用状态以便其他线程获取连接
  bagEntry.setState(STATE_NOT_IN_USE);
  for (int i = 0; waiters.get() &gt; 0; i++) {
     // 传递信号给队列，优先告诉其他阻塞等待获取的线程获取poolEntry
     if (bagEntry.getState() != STATE_NOT_IN_USE || handoffQueue.offer(bagEntry)) {
        return;
     }
     // 循环多次后，等待阻塞10纳秒
     else if ((i &amp; 0xff) == 0xff) {
        parkNanos(MICROSECONDS.toNanos(10));
     }
     else {
        // 让出时间片
        Thread.yield();
     }
  }

  // 更新最新poolEntry的本地线程的缓存中，以便当前线程下次获取连接
  final List&lt;Object&gt; threadLocalList = threadList.get();
  if (threadLocalList.size() &lt; 50) {
     // 对应上文中的fastList, 每次新增都是放到数组最后面
     threadLocalList.add(weakThreadLocals ? new WeakReference&lt;&gt;(bagEntry) : bagEntry);
  }
}
</code></pre>
<p>最后我们分析以下remove方法，很简单</p>
<pre><code class="language-java">public boolean remove(final T bagEntry)
   {
      if (!bagEntry.compareAndSet(STATE_IN_USE, STATE_REMOVED) &amp;&amp; !bagEntry.compareAndSet(STATE_RESERVED, STATE_REMOVED) &amp;&amp; !closed) {
         LOGGER.warn(&quot;Attempt to remove an object from the bag that was not borrowed or reserved: {}&quot;, bagEntry);
         return false;
      }
      // 从所有缓存的list去除
      final boolean removed = sharedList.remove(bagEntry);
      // 从当前本地线程缓存中去除
      threadList.get().remove(bagEntry);
      return removed;
   }

</code></pre>
<p>什么时候会调用remove，笔者总结了以下：<br>
1、当调用datasource shutdown方法时候<br>
2、当前connetion没有用的时候（可能是MySQL服务器down机）<br>
3、当前conntion被标记为丢弃时候，超过了maxLifetime被标记为丢弃<br>
4、当前connetion的最后一次使用时间和当前时间的差值大于idleTimeout时候</p>
<p>以上可以理解了从初始化到getConnection获取连接，到closeConnectiond的核心逻辑，实现了核心逻辑的小闭环。</p>
<h2 id="三-自己写个连接池需要考虑哪些方面">三、自己写个连接池需要考虑哪些方面</h2>
<p>根据上面分析的源码，可以看到，如果自己实现一个连接池的话，需要考虑：</p>
<ol>
<li>初始化的步骤，初始化最初的最小空闲数连接</li>
<li>取连接，从连接池中取，并且要上锁</li>
<li>归还连接，需要放回到连接池中，要上锁</li>
<li>如果连接池全被占用，是返回失败，还是让上游等待</li>
<li>拿到的连接，需要检测这个连接是否可用，是否还是活的，因为不知道服务端是否挂掉，抑或是连接超过maxlife被标记为evit正在关闭</li>
<li>连接池用什么数据结构存储，数组还是链表，还要考虑并发安全</li>
</ol>
<h2 id="四-总结">四、总结</h2>
<p>本篇文章从源码角度分析了一波，明白了为什么HikariDataSource是业界性能最高连接池的原因。我们可以更深入理解连接池背后的工作原理，以便后面出了线上问题可以轻松应对。最后读者可以试试自己实现一个连接池加深理解。<br>
以上文章有任何表达上或者技术问题欢迎指正。</p>
<h2 id="四-参考">四、参考</h2>
<ol>
<li>数据库连接池之Hikari源码解析——https://www.cnblogs.com/jackion5/p/14193025.html</li>
</ol>
]]></content>
    </entry>
    <entry>
        <title type="html"><![CDATA[记一次多数据源路由造成的数据库连接泄露排查过程]]></title>
        <id>https://zhangyaoo.github.io/post/ji-yi-ci-duo-shu-ju-yuan-lu-you-zao-cheng-de-shu-ju-ku-lian-jie-nei-cun-xie-lu/</id>
        <link href="https://zhangyaoo.github.io/post/ji-yi-ci-duo-shu-ju-yuan-lu-you-zao-cheng-de-shu-ju-ku-lian-jie-nei-cun-xie-lu/">
        </link>
        <updated>2021-02-02T03:32:16.000Z</updated>
        <content type="html"><![CDATA[<h3 id="前言">前言</h3>
<p>之前一篇文章讲了自己写了一个多数据源路由组件给公司内部使用，进行快速迭代。文章URL是 <a href="https://zhangyaoo.github.io/post/saas-xi-tong-duo-shu-ju-yuan-lu-you-you-ya-jie-jue-fang-an">SaaS系统多数据源路由优雅解决方案</a><br>
随着时间推移，某一天运维找上门说数据库连接打满，就刚好这一台机器上装了Java服务导致的。<br>
下面文章就是讲的这次连接泄露导致的数据库hang住问题以及后面的解决过程。</p>
<h3 id="一-案发当时的情况">一、案发当时的情况：</h3>
<p>线上MySQL session 逐渐增加，不活跃的的数量逐渐增加，导致的后果：占用链接，导致链接满了无法分配新的连接<br>
<img src="https://zhangyaoo.github.io/post-images/1612261925869.jpg" alt="" loading="lazy"></p>
<h3 id="二-紧急处理方式">二、紧急处理方式：</h3>
<p>用自研的应用层网关将流量切换为旧的版本中，并且不停机切换，然后将当前的版本的服务停调，然后观察阿里云的数据库连接数量变回正常。</p>
<p>目前线上存在多个版本存在docker，然后用K8s部署，实现快速不停机切换上线。<br>
自研网关这篇文章有介绍： <a href="https://zhangyaoo.github.io/post/ying-yong-ceng-wang-guan-she-ji-yu-shi-xian">应用层网关设计和实现</a></p>
<h3 id="三-第一次查找问题并且解决的过程">三、第一次查找问题并且解决的过程：</h3>
<p>1、开启本地服务，让它飞一会，或者多线程并且切租户查询数据库，dump内存快照进行分析<br>
<img src="https://zhangyaoo.github.io/post-images/1612253583270.png" alt="" loading="lazy"></p>
<p>2、然后查看本地服务相关数据库连接的对象<br>
1）分析sqlsession 对象，发现sqlsession对象为0，而且日志中有打印及时关闭sqlsession。结论：sqlsession正常，说明正常关闭了sqlsession<br>
<img src="https://zhangyaoo.github.io/post-images/1612237357285.png" alt="" loading="lazy"><br>
2）分析datasource 对象，发现datasource对象和数据库连接配置中的max-pool-size一致。结论：datasource正常，说明正常关闭了datasource<br>
<img src="https://zhangyaoo.github.io/post-images/1612237380060.png" alt="" loading="lazy"><br>
3）分析connection对象，发现HikariProxyConnection对象和数据库配置一致。结论：HikariProxyConnection正常<br>
<img src="https://zhangyaoo.github.io/post-images/1612237411657.png" alt="" loading="lazy"></p>
<p>3、在分析本地内存快照，发现一个类随着时间的推移，逐渐增多，并且没有被回收，正是connectionImpl对象，这个对象是MySQL底层连接的实现，来自com.mysql.cj.jdbc<br>
<img src="https://zhangyaoo.github.io/post-images/1612237433473.png" alt="" loading="lazy"><br>
（图片中指的类有100多个对象）</p>
<p>4、跟踪了一波源码，发现HikariProxyConnection对象，实质上底层就是new了一个并管理connectionImpl对象，猜测某个因为参数原因导致HikariProxyConnection及时释放，而connectionImpl没有释放，积累没有及时清除导致的。</p>
<p>5、经过Google查找问题，怀疑是max_lifetime导致的问题。max_lifetime官网解释：一个连接的生命时长（毫秒），超时而且没被使用则被释放（retired）。建议比数据库的wait_timeout小几分钟。默认30分钟<br>
<img src="https://zhangyaoo.github.io/post-images/1612237640791.png" alt="" loading="lazy"></p>
<p>6、查看线上配置和测试环境配置，果然是只配置了1分钟。<img src="https://zhangyaoo.github.io/post-images/1612262047685.jpg" alt="" loading="lazy"><br>
随后将其改成30分钟，然后继续多线程并发跑测试用例。测试环境验证，dump内存，观察connectionImpl对象并没有随着时间的推移增加。发现connectionImpl对象并没有随着时间的推移增加。验证了个人的猜想。<br>
<img src="https://zhangyaoo.github.io/post-images/1612237699007.png" alt="" loading="lazy"></p>
<p>7、最终将配置更新后上线，过了没2个小时，连接数又飙升。初步观察还是connectionImpl对象增多，连接没有释放。所以认为，不是max_lifetime配置的问题。还是得从源码中入手和线上的dump入手看。</p>
<p>第一次查找问题并<strong>没有解决根本问题</strong>，对此总结了一下：</p>
<ol>
<li>自己的猜想缺少实际的数据支持和多方位的有力证明</li>
<li>对源码研究不够深入，只是停留在表明</li>
<li>对官网的配置参数理解不够透彻</li>
</ol>
<h3 id="四-第二次查找问题并且解决的过程">四、第二次查找问题并且解决的过程：</h3>
<p>本地环境观察没有问题，正式环境观察就有问题。像这种问题算是比较难解决的，为了快速解决问题，避免把线上数据copy到本地进行测试，直接down线上的dump文件下来进行仔细分析。</p>
<p>1、查找线上的内存，dump数量，刚好100个，并且随着时间偏移，这个类对象越来越多，个人猜想就是这个对象没有被回收导致连接数未释放。有强引用引用这个对象。<br>
<img src="https://zhangyaoo.github.io/post-images/1612420897419.png" alt="" loading="lazy"></p>
<p>2、查找这个对象GC root对象，右键选择Merge Shortest Paths to GC roots -&gt; exclude all phantom/weak/soft etc.reference(排除所有虚弱软引用)，发现这100个对象大部分被一个名字叫做housekeeper线程所强引用，如下图。个人验证猜想是线程没有及时回收关闭或者是没有关闭线程池。<br>
<img src="https://zhangyaoo.github.io/post-images/1612423498302.png" alt="" loading="lazy"></p>
<p>3、这个时候dump文件里面就没法发现更多有用的信息了，然后就去看源码看这个housekeeper线程为什么一直强引用。查找源码发现在获取datasource 的 getConnetcion方法，会初始化HikariPool连接池。<br>
<img src="https://zhangyaoo.github.io/post-images/1612423896839.png" alt="" loading="lazy"></p>
<p>初始化连接池里面会初始化housekeeper连接池，刚好对应了上面在根引用的对象。<br>
<img src="https://zhangyaoo.github.io/post-images/1612423966034.png" alt="" loading="lazy"><br>
<img src="https://zhangyaoo.github.io/post-images/1612425624943.png" alt="" loading="lazy"></p>
<p>看了下这个housekeeper对象的作用，目的是为了维持最少的空闲的连接，说白了就是根据配置参数idleTimeout和minIdle来维持最小的空闲连接数。<br>
<img src="https://zhangyaoo.github.io/post-images/1612425545450.png" alt="" loading="lazy"></p>
<p>4、至此，可以初步得出结论，是由于应用程序不停的new HikariPool，然后没有及时close导致的问题。然后顺着这个结论去查看应用程序的BUG</p>
<p>5、在程序发现下面逻辑，下面这一段逻辑就是根据租户来获取缓存中租户对应的datasource对象</p>
<pre><code class="language-java">   /**
     * 获取已缓存的数据源
     */
    private Optional&lt;DataSource&gt; getDataSourceIfCache(SelectRdsConfigDto rdsConfigDto) {
        String key = getUniqueMysqlKey(rdsConfigDto.getHost(), rdsConfigDto.getPort());
        if (Objects.nonNull(dataSourceCachePool.get(key))) {
            DataSourceCache dataSourceCache = dataSourceCachePool.get(key);
            //cache中已经缓存了租户的连接并且没有修改rds config信息
            if (dataSourceCache.verifyRdsConfig(rdsConfigDto)) {
                return Optional.ofNullable(dataSourceCachePool.get(key).getDataSource());
            }
            //cache中已经缓存了租户的连接，但是校验不通过
            else {
                dataSourceCachePool.remove(key);
                return Optional.empty();
            }
        }
        return Optional.empty();
    }

   // 校验
   private boolean verifyRdsConfig(SelectRdsConfigDto rdsConfigDto) {
        return rdsConfigDto.getAccount().equals(this.account) &amp;&amp;
                rdsConfigDto.getHost().equals(this.host) &amp;&amp;
                rdsConfigDto.getPort().equals(this.port) &amp;&amp;    rdsConfigDto.getPwd().equals(this.pwd) &amp;&amp;；

    //  dataSourceCachePool的key组成，一个MySQL连接对应的key
    private String getUniqueMysqlKey(String host, Integer port){
        return host + &quot;:&quot; + port;
    }

 }
</code></pre>
<p>这里逻辑有一段是校验不通过，会remove对应的datasource对象，问题就出现在这里，这里没有及时close。校验不通过的原因就是，一个host port作为一个dataSourceCachePool的key，因为线上有一个MySQL实例多个账号，导致校验总是不通过误以为成是修改了用户名或者密码，随后就是一直new datasource对象。</p>
<h3 id="五-根本原因">五、根本原因</h3>
<p>所以综上，最终得出结论是，因为程序问题导致HikariDataSource对象增多，而且因为HikariDataSource对象内部有一个线程池，如果外部丢失了对这个HikariDataSource对象的引用，也不会被垃圾回收，导致HikariDataSource对象不释放，然后结果就是数据库连接未释放。</p>
<h3 id="六-最终处理方式">六、最终处理方式：</h3>
<p>1、修改代码：<br>
1） dataSourceCachePool的key组成由host port 改成 host port account pwd 四个维度作为一个key。</p>
<p>Q：为什么要这四个维度作为一个key ？<br>
A：因为避免一个rds有多个账户密码，导致dataSourceCachePool无限put相同host port，避免一直new datasource 和close datasource，浪费资源。</p>
<p>2）关闭datasource对象，remove那段代码的逻辑修改成下面这个样子</p>
<pre><code class="language-java">//cache中已经缓存了租户的连接,但是修改了rds config信息
        DataSource dataSource = dataSourceCachePool.remove(key).getDataSource();
        log.info(&quot;remove datasource:{}, {}&quot;, key, rdsConfigDto.toString());
        new Thread(() -&gt; {
            while (true) {
                try {
                    TimeUnit.SECONDS.sleep(10);
                } catch (InterruptedException e) {
                    log.error(&quot;e:&quot;, e);
                }
                if (dataSource instanceof HikariDataSource) {
                    if (((HikariDataSource) dataSource).getHikariPoolMXBean().getActiveConnections() &gt; 0){
                        log.info(&quot;ActiveConnections &gt; 0, continue&quot;);
                        continue;
                    }
                    log.info(&quot;HikariDataSource close...&quot;);
                    ((HikariDataSource) dataSource).close();
                } else if (dataSource instanceof DruidDataSource) {
                    if (((DruidDataSource) dataSource).getActiveCount() &gt; 0) {
                        log.info(&quot;ActiveConnections &gt; 0, continue&quot;);
                        continue;
                    }
                    log.info(&quot;DruidDataSource close...&quot;);
                    ((DruidDataSource) dataSource).close();
                } else {
                    log.error(&quot;close datasource|datasource is wrong&quot;);
                    throw new RuntimeException(&quot;close datasource|datasource is wrong&quot;);
                }
                break;
            }
        }).start();
</code></pre>
<p>Q：为什么要判断活跃的连接 ActiveCount &gt; 0 ？<br>
A：因为close的时候要判断是否有正在使用的connection对象，如果强制关闭，那么会出现一个线程查询的时候，connetion突然不可用，导致错误。</p>
<p>Q：为什么不用线程池，而是直接new Thread ？<br>
A：这个场景笔者也有考虑，但是这种场景很少，一般不会有，除非手动修改数据库配置。很少使用的场景，如果开个线程池一直放着，也耗系统资源。</p>
<p>2、改配置，改成和官方默认的配置<br>
<img src="https://zhangyaoo.github.io/post-images/1612426469625.png" alt="" loading="lazy"></p>
<p>最后，重新上线后，观测对象内存数据，正常。观察3306端口连接数，正常。<br>
<img src="https://zhangyaoo.github.io/post-images/1613802463906.png" alt="" loading="lazy"></p>
<h3 id="七-总结">七、总结</h3>
<p>底层的数据库组件的代码编写，要注意使用数据库连接资源的时候，一定要检查代码中是否释放，不然会造成严重的事故。而且平常还要熟悉官方配置，并且多研究源码。以免出现这种情况时束手无策。<br>
可以的话还可以叫身边的资深大牛给review代码，做到双重保障。</p>
<p>最后非常感谢组内小伙伴的技术支持，才能一步一步的排除出问题，找出问题所在</p>
]]></content>
    </entry>
    <entry>
        <title type="html"><![CDATA[2020年总结]]></title>
        <id>https://zhangyaoo.github.io/post/2020-nian-zong-jie/</id>
        <link href="https://zhangyaoo.github.io/post/2020-nian-zong-jie/">
        </link>
        <updated>2020-12-31T03:59:36.000Z</updated>
        <content type="html"><![CDATA[<figure data-type="image" tabindex="1"><img src="https://zhangyaoo.github.io/post-images/1609517863900.jpg" alt="" loading="lazy"></figure>
<h3 id="开头">开头</h3>
<p>今天是1月1号，新年第一天，抓住2020年的小尾巴，随便絮絮叨叨一下，做个小总结。回想一下今年一整年，开心，困难，心酸，大部分都经历过，没有什么值得说的经历，倒是小事挺多。</p>
<p>值得提的事情就是疫情了，今年疫情在家呆了2个月，那时候因为年前被裁，已经是失业的状态，没有收入来源，开始坐立不安，烦躁 。后面意识到了在家也有在家值得做的事情，不必因为疫情打乱自己的内心，充实陪家人过每一天。</p>
<p>作为成年人，现在认为时常开心快乐倒是一件很难的事情，想起一句话，小时候快乐是一件简单的事情，长大后，简单是一件快乐的事情。不过后面还是要时常开心为主，然后就是今年以后要沉静下来，理性思考，不管对人还是对事。还要多看些关于生活上的书，不只是盯着技术书死啃，提醒一下自己要停下来多思考，低头做事，抬头看路。</p>
<p>今年总结方面有些少，因为我自己认为这些方面值得去总结，至于其他的，可能我没有意识到或者是今年经历事情的太少。</p>
<h3 id="学习">学习</h3>
<p><img src="https://zhangyaoo.github.io/post-images/1609517630829.jpg" alt="" loading="lazy"><br>
关于学习这件事，还是要放在第一来说。学无止境，活到老学到老。人不能总是停留在原地，还是要多看书多学习，增长知识。中国人大部分劳动人民以前（80年代）是基本靠努力，靠勤奋，获得属于自己的劳动果实，现在信息时代，除了靠努力勤奋以外，还要有效利用专业知识去解决生活工作中的问题，享受现在信息时代给与的成果。<br>
就像文臣武将，谋士当出谋划策，武士当战场厮杀。每个人当去发挥自己的专业本领。不管最终目的是啥，精忠报国还是养家糊口，小有小义，大有大义。</p>
<p>扯远了，今年准备还是以技术学习为主，然后以公众号和GitHub为辅助进行学习。<br>
今年准备看完这些学习资料，其中有书籍以及网络课程<br>
1、MySQL是如何运行的<br>
2、redis设计和实现<br>
3、架构师视频课<br>
4、极客时间MySQL<br>
5、Netty网络编程学习+技术书籍+Netty实战</p>
<p>不多，列多了就看不完了[dog]。</p>
<p>其他则按时及时总结工作上遇到的问题，提升自己的技术深度。毕竟工作中遇到的最容易加深理解的和提升能力的。<br>
顺便看一些优秀的博客及时总结，输出自己的理解。然后维护到自己的个人网站上面去。</p>
<p>然后其他时间，准备看一些其他类型的书籍，比如人文历史，以及其他优秀的国内外著作，现在已经想好看些什么，就不一一列举了，今年今后会抽空余时间去看这些，提升自己对人和生活的一些思考。</p>
<p>最后的话要提醒自己少看动漫二次元多学习，早睡早起~~</p>
<h3 id="运动">运动</h3>
<p><img src="https://zhangyaoo.github.io/post-images/1609517659211.jpg" alt="" loading="lazy"><br>
运动这件事情，算是我个人每年立的flag中，自己最满意的了。一周最少一次跑步+篮球。基本上也不算全部，每周都做了。<br>
我身边的朋友或者亲人，我会经常提醒他们，要适当的锻炼。虽然总是被当作耳边风，但是每次过年祝别人身体健康只是噱头，只有真正关心你的人会在乎你的健康。我个人不管是生日还是新年愿望，大部分都是希望身边的人过的平平安安开开心心就行了，其他都是扯淡。<br>
而我自己运动的动力来源是，如果我自己身体不行，那就没有能力照护身边人。我自己能够成长为大树，让别人安心倚靠。</p>
<p>现在虽然毕业了3年，6块腹肌已经变成了4快，身体没有毕业那会好，但是我自己还是会坚持的，朝着更man的目标奋斗。想当年我可是拥有8块腹肌的男人。。。。</p>
<h3 id="爱情">爱情</h3>
<p><img src="https://zhangyaoo.github.io/post-images/1609517842818.jpg" alt="" loading="lazy"><br>
今年最开心的就是和女朋友度过第一年的恋爱期（不要脸的我，自认为网恋了一年的热恋期），这一年有开心和难过，不过难过时刻很少，大部分都是开心时刻，我觉得已经可以了，能够和对方每天都很开心，已经很不错了。毕竟和喜欢的人在一起不就是开心撒，这个是最难能可贵的。。</p>
<p>我自认为我是个不好i相处的人，个人的小脾气很多，而且有时候会常有不自信。谢谢我女朋友的理解和鼓励。今年往后，还希望一起开心度过每一天，哈哈哈哈。</p>
<p>新的一年，希望咱俩都身体健康，开开心心~</p>
<h3 id="2021flag">2021flag</h3>
<p>国际惯例，最后说一些打脸的flag<br>
1、完成上面的资料的学习<br>
2、每个月一次文章总结，工作总结，4次个人网站文章的发表和维护<br>
3、一周一次运动+篮球<br>
4、身体体重不超130<br>
5、经营好个人博客<br>
6、 早睡早起，11点半之前睡</p>
<p><strong>2021年，干就完事</strong>。<br>
<img src="https://zhangyaoo.github.io/post-images/1609517948326.jpg" alt="" loading="lazy"></p>
]]></content>
    </entry>
    <entry>
        <title type="html"><![CDATA[概率相等的拼手气红包算法实现]]></title>
        <id>https://zhangyaoo.github.io/post/shou-lu-yi-ge-hong-bao-suan-fa/</id>
        <link href="https://zhangyaoo.github.io/post/shou-lu-yi-ge-hong-bao-suan-fa/">
        </link>
        <updated>2020-12-17T14:17:09.000Z</updated>
        <content type="html"><![CDATA[<h3 id="1-要求">1、要求</h3>
<p>红包算法 function：拼手气红包<br>
1、每个红包获得的数学概率要一样<br>
2、红包最小值：1分钱</p>
<h3 id="2-思路">2、思路：</h3>
<p>利用切片的思想，比如有5个红包，20分，就从0-20的范围内获取四个随机数，就被分成5份，然后顺序抽取。这样保证每个红包的的概率一样<br>
这种方案需要考虑到几个注意点：<br>
1）重复的随机切片如何处理；<br>
2）需要考虑1分钱如何处理；</p>
<h3 id="3-实现">3、实现：</h3>
<p>遇到随机切片重复:重新生成切片直至不重复<br>
1分钱处理：判断相邻间隔的大小</p>
<p>###4、 代码实现：<br>
利用treeMap的顺序有序性</p>
<p>直接上代码（笔者已经调试过没有问题，可以运行）</p>
<pre><code class="language-java">public class RedPackage {
   /**
    * 红包最小金额
    */
   private long minAmount = 1L;

   /**
    * 最大的红包是平均值的N倍
    */
   private static final long N = 2;

   /**
    * 红包最大金额
    */
   private long maxAmount;

   /**
    * 红包金额 分
    */
   private long packageAmount;

   /**
    * 红包个数
    */
   private long packageSize;

   /**
    * 是否抢完
    */
   private boolean finish;

   /**
    * 存储红包的金额顺序
    */
   private final TreeMap&lt;Long, Long&gt; treeMap = Maps.newTreeMap((o1, o2) -&gt; o1 &gt; o2 ? 1 : o1.equals(o2) ? 0 : -1);

   /**
    * 构造函数不写业务逻辑
    */
   public RedPackage(long packageAmount, int packageSize){
       this.packageAmount = packageAmount;
       this.packageSize = packageSize;
       maxAmount = (packageAmount * N)/ packageSize;
   }

   public RedPackage(long packageAmount, int packageSize, long minAmount){
       this.packageAmount = packageAmount;
       this.packageSize = packageSize;
       this.minAmount = minAmount;
   }

   /**
    * 获取金额
    */
   public synchronized long nextAmount(){
       // 前置校验，初始化
       if(!finish &amp;&amp; treeMap.size() == 0){
           treeMap.put(packageAmount, 0L);
           for (int i = 0; i &lt; packageSize - 1; i++) {
               // 随机抽取切片
               long splitNum = RandomUtils.nextLong(minAmount, packageAmount);
               Long higher = treeMap.higherKey(splitNum);
               higher = higher == null ? packageAmount : higher;
               Long lower = treeMap.lowerKey(splitNum);
               lower = lower == null ? 0 : lower;
               // 相同切片重新生成,和上一个或者下一个切片间隔小于minAmount的重新生成
               while (higher - splitNum &lt;= minAmount
                       || splitNum - lower &lt;= minAmount
                       || treeMap.containsKey(splitNum)){
                   splitNum = RandomUtils.nextLong(minAmount, packageAmount);
               }
               // value放入上一个entry的key,组成链条，防止再次循环
               treeMap.put(splitNum, lower);
               treeMap.put(higher, splitNum);
           }
           System.out.println(&quot;init finish&quot;);
       }
       Map.Entry&lt;Long, Long&gt; entry = treeMap.pollFirstEntry();
       if(treeMap.size() == 0){
           // 用完红包
           this.finish = true;
           if(entry == null){
               return 0L;
           }
       }
       return entry.getKey() - entry.getValue();
   }

   public static void main(String[] args) {
       RedPackage redPackage = new RedPackage(1500L, 10, 10L);
       long result = 0;
       for (int i = 0; i &lt; 15; i++) {
           long amount = redPackage.nextAmount()；
           System.out.println(amount);
           result = result + amount;
       }
       System.out.println(result);
   }
}
</code></pre>
<h3 id="5-todo-设置单个红包最大限额值">5、TODO 设置单个红包最大限额值</h3>
<p>目前还没有实现思路</p>
]]></content>
    </entry>
    <entry>
        <title type="html"><![CDATA[学习笔记：MySQL]]></title>
        <id>https://zhangyaoo.github.io/post/xue-xi-bi-ji-mysql/</id>
        <link href="https://zhangyaoo.github.io/post/xue-xi-bi-ji-mysql/">
        </link>
        <updated>2020-11-12T10:46:53.000Z</updated>
        <content type="html"><![CDATA[<h2 id="幻读原理">幻读原理</h2>
<h3 id="1-定义">1、定义：</h3>
<p>幻读指的是一个事务在前后两次查询同一个范围的时候，后一次查询看到了前一次查询没有看到的行<br>
幻读：提交隔离级别下看到的，严格来说不算。因为这个就是读提交隔离级别下“设计内”的问题<br>
对于读提交隔离级别，这个算“feature”,对于可重复读，这个是”bug”, 所以要解决，称呼这个bug为幻读</p>
<h3 id="2-注意">2、注意：</h3>
<ol>
<li>在可重复读隔离级别下，普通的查询是快照读，是不会看到别的事务插入的数据的。因此，幻读在“当前读”下才会出现。</li>
<li>幻读只针对新增的行，即使把所有的记录都加上锁，还是阻止不了新插入的记录</li>
<li>间隙锁是在可重复读隔离级别下才会生效的。如果把隔离级别设置为读提交的话，就没有间隙锁了。</li>
<li>隔离级别为读提交的话，就会出现幻读【严格来说RC级别下不是幻读】情况。并且需要将binlog的模式设置为row模式（binlog三种模式https://www.cnblogs.com/xingyunfashi/p/8431780.html），不能使用statement格式，statement会导致数据一致性问题（没有间隙锁）</li>
</ol>
<p>为什么要设置为row？<br>
间隙锁是在可重复读隔离级别下才会生效的。所以，你如果把隔离级别设置为读提交的话，就没有间隙锁了。但同时，你要解决可能出现的数据和日志不一致问题，需要把 binlog 格式设置为 row。</p>
<ol start="5">
<li>主键之间也会也有间隙锁，如下图，执行select * from t where id=N for update; 如果没有这行会锁住间隙(5,10)(有一条5和一条10的记录)。如下图，多线程执行语句会导致死锁<br>
<img src="https://zhangyaoo.github.io/post-images/1614246510870.png" alt="" loading="lazy"></li>
</ol>
<h3 id="3-解决">3、解决：</h3>
<p>间隙锁和行锁，合成为next-key lock，next-key lock是前开后闭区间，单独间隙锁是前开后开区间</p>
<h3 id="4-后果">4、后果：</h3>
<p>间隙锁的引入，可能会导致同样的语句锁住更大的范围，影响并发度</p>
<h3 id="5-案例">5、案例</h3>
<p>案例1、select * from t where d=5 for update，d没有索引<br>
这个时候会扫描全表，会给表记录所有的行加上行锁，还会加上间隙锁。比如表t有6条记录，会上6条行锁，以及7个间隙锁。<br>
结论：对于非索引字段进行update或select .. for update操作，代价极高。所有记录上锁，以及所有间隔的锁。对于索引字段进行上述操作，代价一般。只有索引字段本身和附近的间隔会被加锁。</p>
<h2 id="online-ddl-原理">online DDL 原理</h2>
<h3 id="1-mdl锁表元数据锁在online-ddl的体现">1、MDL锁（表元数据锁）在online DDL的体现？</h3>
<p>作用：维护表元数据的数据一致性，保证DDL操作与DML操作之间的一致性。如果在SQL查询期间修改了表结构就会有问题。<br>
总结：MDL作用是防止DDL和DML并发的冲突</p>
<h3 id="2-过程">2、过程</h3>
<ol>
<li>
<p>当对一个表做增删改查操作的时候，加 MDL 读锁；当要对表做结构变更操作的时候，加 MDL 写锁。<br>
结论：加读锁则所有线程可正常读元数据，不影响增删改查操作，只是不能修改表结构；加写锁则只有拥有锁的线程可以读写元数据，也就是修改表结构，其它线程不能执行任何操作，包括修改表结构与增删改查。</p>
</li>
<li>
<p>事务中的 MDL 锁，在语句执行开始时申请，但是语句结束后并不会马上释放，而会等到整个事务提交后再释放。<br>
注：一般增删改查语句默认加上MDL读锁<br>
结论：当有未提交的事务时候，或者是长事务时候，如果这个时候进行增删改查，是一个危险的操作，可能阻塞其它增删改查请求，或导致线程爆满。</p>
</li>
</ol>
<h3 id="3-online-ddl工作原理">3、online DDL工作原理</h3>
<ol>
<li>拿MDL写锁</li>
<li>DDL执行准备</li>
<li>降级成MDL读锁</li>
<li>DDL核心执行（耗时最多的）</li>
<li>升级成MDL写锁</li>
<li>DDL最终提交</li>
<li>释放MDL锁<br>
注：除了第四步，其他都是获取锁，如果没有冲突，获取锁的时间较小。其中第四步是读锁，所以是可以正常读写数据所以被称为Online DDL。</li>
</ol>
<h2 id="oderby-工作原理">oderby 工作原理</h2>
<h3 id="1-引出">1、引出</h3>
<p>explain 的extra信息里面出现了filesort，MySQL 会给每个线程分配一块内存用于排序，称为 sort_buffer。</p>
<p>sort_buffer_size，就是 MySQL 为排序开辟的内存（sort_buffer）的大小。如果要排序的数据量小于 sort_buffer_size，排序就在内存中完成。但如果排序数据量太大，内存放不下，则不得不利用磁盘临时文件辅助排序。<br>
外部排序一般使用归并排序算法。</p>
<h3 id="2-排序类型">2、排序类型</h3>
<p>全字段排序和rowID排序<br>
全字段排序：会找出主键索引的所有字段数据放入sort_buffer中排序<br>
缺点：返回的字段很多的话，那么 sort_buffer 里面要放的字段数太多，这样内存里能够同时放下的行数很少，要分成很多个临时文件，排序的性能会很差</p>
<p>rowID排序：要排序的列只有排序字段和ID<br>
缺点:rowid 排序多访问了一次表 t 的主键索引，多了磁盘读</p>
<p>MySQL设计思想：如果内存够，就要多利用内存，尽量减少磁盘访问。</p>
<h3 id="3-增加覆盖索引和联合索引优化排序">3、增加覆盖索引和联合索引优化排序</h3>
<p>索引默认数据是有序的，这样可以避免使用sort_buffer（全字段排序和rowID排序）来进行排序</p>
<h3 id="4-额外案例">4、额外案例</h3>
<p>1）无条件查询如果只有order by create_time（create_time是索引），那么不会走索引<br>
原因：优化器认为走二级索引再去回表成本比全表扫描排序更高，所以选择走全表扫描，然后利用全字段排序和rowID排序其中一种排序。</p>
<h2 id="select-count工作原理">select count工作原理</h2>
<h3 id="1-count-实现方式">1、count(*) 实现方式</h3>
<p>在不同的 MySQL 引擎中，count(<em>) 有不同的实现方式。<br>
MyISAM 引擎把一个表的总行数存在了磁盘上，因此执行 count(</em>) 的时候会直接返回这个数，效率很高；<br>
而 InnoDB 引擎就麻烦了，它执行 count(*) 的时候，需要把数据一行一行地从引擎里面读出来，然后累积计数。</p>
<h3 id="2-为什么innodb-不跟-myisam-一样也把数字存起来呢">2、为什么InnoDB 不跟 MyISAM 一样，也把数字存起来呢</h3>
<p>因为InnoDB 有MVCC，不同时刻不同事务之间有可能的结果不一样</p>
<h3 id="3-小结一下">3、小结一下</h3>
<p>MyISAM 表虽然 count(<em>) 很快，但是不支持事务；，加了where条件也很慢<br>
show table status 命令虽然返回很快，但是不准确；<br>
InnoDB 表直接 count(</em>) 会遍历全表，虽然结果准确，但会导致性能问题</p>
<h3 id="4-count-count主键-id-count字段-和-count1-等不同用法的性能有哪些差别">4、count(*)、count(主键 id)、count(字段) 和 count(1) 等不同用法的性能，有哪些差别？</h3>
<p>count语义：count() 是一个聚合函数，对于返回的结果集，一行行地判断，如果 count 函数的参数不是 NULL，累计值就加 1，否则不加。最后返回累计值<br>
得出结论：count(*)、count(主键 id) 和 count(1) 都表示返回满足条件的结果集的总行数；而 count(字段），则表示返回满足条件的数据行里面，参数“字段”不为 NULL 的总个数</p>
<h3 id="5-性能对比">5、性能对比：</h3>
<p>count(主键ID)：InnoDB 引擎遍历整张表，但不取值。server 层拿到 id 后，判断是不可能为空的，就按行累加<br>
count(1)：InnoDB 引擎遍历整张表，把每一行的ID取出来。server 层对于返回的每一行，放一个数字“1”进去，判断是不可能为空的，按行累加<br>
count(字段)：一行行地从记录里面读出这个字段，判断不能为 null，按行累加<br>
count(<em>)：count(</em>)是个例外，目前MySQL只针对了这个做了优化，并不会把全部字段取出来，而是专门做了优化，不取值。count(*) 肯定不是 null，按行累加。</p>
<h3 id="6-结论">6、结论</h3>
<p>count(字段) &lt; count(主键ID)&lt; count(1)=count(<em>)<br>
1、因为count(</em>) 和 count(1) 不取字段值，引擎层减少往 server层的数据返回，所以比其他count(字段)要返回值的【性能】较好；<br>
2、为什么count(字段)&lt; count(主键ID)，因为如果选择count(ID)，那么MySQL会自动选择最小的索引树来遍历，如果是count(字段)，而且字段没有索引，那么会使用主键索引。主键索引很大。</p>
<h2 id="普通索引和唯一索引选择">普通索引和唯一索引选择</h2>
<h3 id="1-普通索引和唯一索引选择">1、普通索引和唯一索引选择</h3>
<ol>
<li>查询性能都一样</li>
<li>更新分两种情况</li>
</ol>
<ol>
<li>这个记录要更新的目标页在内存中：<br>
对于唯一索引来说，找到 3 和 5 之间的位置，判断到没有冲突，插入这个值，语句执行结束；<br>
对于普通索引来说，找到 3 和 5 之间的位置，插入这个值，语句执行结束。<br>
总结：目标记录在内存buffer pool中的话，普通索引和唯一索引更新性能是一致的。</li>
</ol>
<p>2)这个记录要更新的目标页不在内存中：<br>
对于唯一索引来说，需要将数据页读入内存，判断到没有冲突，插入这个值，语句执行结束；<br>
对于普通索引来说，则是将更新记录在 change buffer，语句执行就结束了。<br>
总结：唯一索引将数据页读入内存涉及随机访问IO，操作成本极高。change buffer避免更新磁盘，减少了随机磁盘访问，提供性能。</p>
<p>案例：某个业务的库内存命中率突然从 99% 降低到了 75%，整个系统处于阻塞状态，更新语句全部堵住<br>
原因：业务有大量插入数据的操作，开发人员把其中的某个普通索引改成了唯一索引。</p>
<h3 id="2-changebuffer的使用场景">2、changebuffer的使用场景</h3>
<ol>
<li>唯一索引的更新就不能使用 change buffer，实际上也只有普通索引可以使用。</li>
<li>对于写多读少的业务来说，页面在写完以后马上被访问到的概率比较小，此时 change buffer 的使用效果最好。这种业务模型常见的就是账单类、日志类的系统。</li>
<li>如果是写完立马读的场景，建议关闭change buffer ，因为立马查询会访问数据页，会进行merge操作<br>
merge：将 change buffer 中的操作应用到原数据页，得到最新结果的过程称为 merge。除了访问这个数据页会触发 merge 外，系统有后台线程会定期 merge。在数据库正常关闭（shutdown）的过程中，也会执行 merge 操作。</li>
</ol>
<h3 id="3-change-buffer-和-redo-log两个分别是如何提高性能的">3、change buffer 和 redo log两个分别是如何提高性能的</h3>
<p>redo log 主要节省的是随机写磁盘的 IO 消耗（转成顺序写），<br>
对于普通索引的修改，则会记录到change buffer，而 change buffer 主要节省的则是随机读磁盘的 IO 消耗。</p>
<h3 id="4-举个简单的例子来说明-mergechangebufferredolog的关系">4、举个简单的例子来说明 merge，changebuffer，redolog的关系</h3>
<ol>
<li>
<p>插入(id1,k1) (id2,k2)两条记录，k1 所在的数据页在内存 (InnoDB buffer pool) 中，k2 所在的数据页不在内存中<br>
<img src="https://zhangyaoo.github.io/post-images/1614246819842.png" alt="" loading="lazy"><br>
以上操作是：<br>
1）Page 1 在内存中，直接更新内存；<br>
2）Page 2 没有在内存中，就在内存的 change buffer 区域，记录下“我要往 Page 2 插入一行”这个信3）将上述两个动作记入 redo log 中（图中 3 和 4）。</p>
</li>
<li>
<p>执行查询操作select * from t where k in (k1, k2)<br>
<img src="https://zhangyaoo.github.io/post-images/1614246855416.png" alt="" loading="lazy"><br>
以上操作是：<br>
1）如果k1对应的数据页在buffer pool内存中，那么直接从内存中查出并且返回。这里不用直接从redolog中读盘<br>
2）如果k2对应的数据页不在内存中，那么会读盘，读数据到数据页page2中，然后应用 change buffer 里面的操作日志，做merge操作，并且返回正确的数据</p>
</li>
</ol>
<p>注：</p>
<ol>
<li>此时数据页是脏页，需要刷盘flush</li>
<li>change buffer虽然是在内存中的，如何避免停电导致的丢失呢？<br>
1）.change buffer有一部分在内存有一部分在ibdata.做purge操作,应该就会把change buffer里相应的数据持久化到ibdata<br>
2.）redo log里记录了数据页的修改以及change buffer新写入的信息</li>
</ol>
<h2 id="mysql抖动可能原因">MySQL抖动可能原因</h2>
<h3 id="1-概念">1、概念</h3>
<p>当内存数据页跟磁盘数据页内容不一致的时候，我们称这个内存页为“脏页”。内存数据写入到磁盘后，内存和磁盘上的数据页的内容就一致了，称为“干净页”。内存里的数据写入磁盘的过程，术语就是 flush</p>
<p>更新操作：其实就是在写内存和日志<br>
MySQL 偶尔“抖”一下的那个瞬间：可能就是在刷脏页</p>
<h3 id="2-触发刷flush时机">2、触发刷flush时机</h3>
<ol>
<li>redo log写满<br>
redo log是一个环形的数据结构，当数组redo log写满了，会停止所有的更新操作。checkpoint 往前推进，redo log 留出空间可以继续写。<br>
checkpoint 如果要往前移动，就需要将两个点之间的日志（浅绿色部分），对应的所有脏页都 flush 到磁盘上。</li>
</ol>
<p>这种对数据库影响是很严重的，会停止所有的更新操作<br>
<img src="https://zhangyaoo.github.io/post-images/1614246959529.png" alt="" loading="lazy"></p>
<ol start="2">
<li>
<p>BufferPool内存池无可用内存，需要淘汰脏页，淘汰脏页需要flush<br>
当需要新的内存页，而内存不够用的时候，就要淘汰一些数据页，空出内存给别的数据页使用。这时候只能把最久不使用的数据页从内存中淘汰掉：。如果淘汰的是“脏页”，就要先将脏页写到磁盘。</p>
</li>
<li>
<p>MySQL空闲会主动flush</p>
</li>
<li>
<p>MySQL 正常关闭的情况。<br>
这时候，MySQL 会把内存的脏页都 flush 到磁盘上，下次 MySQL 启动的时候，就可以直接从磁盘上读数据，启动速度会很快。</p>
</li>
</ol>
<h3 id="3-innodb刷脏页的策略">3、Innodb刷脏页的策略</h3>
<p>正确地告诉 InnoDB 所在主机的 IO 能力，通过innodb_io_capacity参数让InnoDB知道磁盘IO能力，以便其正确地刷脏页。<br>
建议：innodb_io_capacity设置为磁盘的 IOPS。 磁盘的 IOPS，也就是在一秒内，磁盘进行多少次 I/O 读写，是衡量磁盘性能的主要指标。</p>
<p>刷脏页慢可能导致的情况：内存脏页太多，其次是 redo log 写满。<br>
总结: 无论是你的查询语句在需要内存的时候可能要求淘汰一个脏页，还是由于刷脏页的逻辑会占用 IO 资源并可能影响到了你的更新语句，都可能是造成你从业务端感知到 MySQL“抖”了一下的原因。</p>
<h3 id="4-具体业务场景">4、具体业务场景</h3>
<p>出现这样的场景：MySQL的TPS会很低，但是主机的IO压力不大<br>
如果是固态硬盘，那么它的IO读写能力会很大。这个时候如果innodb_io_capacity设置太低，MySQL认为磁盘io能力太差，导致全力刷脏页变慢、脏页累积下来，后续只要刷脏页，不管是内存不够还是日志满了导致的刷脏页，都会导致变慢。</p>
<h3 id="5-qa">5 Q&amp;A</h3>
<p>1、“内存不够用了，要先将脏页写到磁盘“redo log对应的空间会释放嘛？“redo log 写满了，要 flush 脏页”对应的内存页会释放嘛？<br>
redolog 的空间是循环使用的，无所谓释放。 对应的内存页会变成干净页。但是等淘汰的时候才会逐出内存</p>
<p>2、redo log是怎么记录对应脏页是否已经flush了？如果断电了重启导致内存丢失，前面几章说通过redo log进行数据恢复那redo log又怎么去释放空间？<br>
不用记，重启了就从checkpoint 的位置往后扫。 如果已经之前刷过盘的, 不会重复应用redo log</p>
<p>3、redolog是记录的什么？<br>
redolog 记录的是动作，不是结果。Redo log记录的是页的偏移量。比如update语句更新+9，Redo log里是记的+9</p>
<p>4：怎么让MySQL不抖？<br>
设置合理参数配配置，尤其是设置 好innodb_io_capacity 的值，并且平时要多关注脏页比例，不要让它经常接近 75%</p>
<p>5：WAL怎么把随机写转化为顺序写的？<br>
写redolog是顺序写的，先写redolog等合适的时候再写磁盘，间接的将随机写变成了顺序写，性能确实会提高不少</p>
]]></content>
    </entry>
    <entry>
        <title type="html"><![CDATA[记一次用户中心采用分布式ID踩的坑]]></title>
        <id>https://zhangyaoo.github.io/post/ji-yi-ci-cai-yong-fen-bu-shi-id-jie-jue-fen-ku-fen-biao-cai-de-keng/</id>
        <link href="https://zhangyaoo.github.io/post/ji-yi-ci-cai-yong-fen-bu-shi-id-jie-jue-fen-ku-fen-biao-cai-de-keng/">
        </link>
        <updated>2020-10-16T02:55:39.000Z</updated>
        <content type="html"><![CDATA[<h3 id="一-背景">一、背景</h3>
<p>随着业务模式的扩大，多个平台下用户数量不断扩大。并且因为业务需要，需要合并两个业务系统的用户中心，因为需要对接三方系统，所以要求用户的ID标识不能体现出系统的用户量。<br>
技术团队考虑到这种场景以及后续用户的扩大，需要一个方案去解决在<strong>分布式环境</strong>下ID递增的问题，系统自己的ID递增算法也需要做改变。</p>
<h3 id="二-业界比较流行的分布式id解决方案">二、业界比较流行的分布式ID解决方案</h3>
<p>技术团队首先考察业界比较流行的做法，总结不同方案优缺点，然后根据自己的业务来选择更合适的方案。</p>
<h4 id="21-数据库分批id分发">2.1 数据库分批ID分发</h4>
<p>数据库分批ID原理主要是利用分批思想以及乐观锁来解决，目前淘宝中间件TDDL其中的主键分配就是用了这个方案。该方案具体是这样做的：</p>
<ol>
<li>数据库表维护一条数据，记录当前分配ID号以及偏移数量等数据</li>
<li>编写服务，利用乐观锁去CAS更新数据，更新成功就说明拿到了一批ID号，失败的话进行重试，设置一定的重试次数</li>
<li>放入本地缓存或者redis做扣减，如果用完就重复步骤2</li>
</ol>
<p>具体的的表可以是类似这样的：</p>
<table>
<thead>
<tr>
<th style="text-align:center">字段</th>
<th style="text-align:center">描述</th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align:center">id</td>
<td style="text-align:center">自增ID，没有业务意义</td>
</tr>
<tr>
<td style="text-align:center">current_num</td>
<td style="text-align:center">当前已经分配的ID最大值</td>
</tr>
<tr>
<td style="text-align:center">limit</td>
<td style="text-align:center">一次分配多少个ID</td>
</tr>
<tr>
<td style="text-align:center">version</td>
<td style="text-align:center">版本号，CAS更新用</td>
</tr>
<tr>
<td style="text-align:center">create_time</td>
<td style="text-align:center">记录创建时间</td>
</tr>
<tr>
<td style="text-align:center">update_time</td>
<td style="text-align:center">记录更新时间</td>
</tr>
</tbody>
</table>
<p>比如，limit=1000，一次分配1000个ID，没分配之前current_num = 0，第一次current_num = 1000，第二次依次类推。</p>
<p>当然，上述的方案也有缺点：</p>
<ol>
<li>一条数据，如果有大量流程去更新，要竞争获取行锁，会有性能问题，（可以参考行锁的利弊，丁奇——秒杀场景下MySQL的低效）</li>
<li>强依赖DB，如果当前数据库宕机，导致分布式ID分发服务就会出现问题</li>
<li>如果在主从数据库场景下，需要考虑到主从的延迟性导致分配ID的不一致性</li>
</ol>
<p>所以为了解决上面的问题，笔者参考concurrentHashMap分段锁的思想，将一条记录分段为多个，同时为了避免DB单点可用性，可以将不同的记录分布在不同的数据库上面。</p>
<p>具体的表可以是类似这样的：</p>
<table>
<thead>
<tr>
<th style="text-align:center">字段</th>
<th style="text-align:center">描述</th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align:center">id</td>
<td style="text-align:center">自增ID，没有业务意义</td>
</tr>
<tr>
<td style="text-align:center">current_num</td>
<td style="text-align:center">当前已经分配的ID最大值</td>
</tr>
<tr>
<td style="text-align:center">limit</td>
<td style="text-align:center">一次分配多少个ID</td>
</tr>
<tr>
<td style="text-align:center">offset</td>
<td style="text-align:center">前后分配的ID间隔数</td>
</tr>
<tr>
<td style="text-align:center">initial_id</td>
<td style="text-align:center">初始自增的ID</td>
</tr>
<tr>
<td style="text-align:center">version</td>
<td style="text-align:center">版本号，CAS更新用</td>
</tr>
<tr>
<td style="text-align:center">create_time</td>
<td style="text-align:center">记录创建时间</td>
</tr>
<tr>
<td style="text-align:center">update_time</td>
<td style="text-align:center">记录更新时间</td>
</tr>
</tbody>
</table>
<p> 新增offset偏移和initial_id字段，offset代表数据库表记录前后分配间隔数量，initial_id代表开始初始的值。<br>
 举个例子，现在将记录分为10条，分布在不同数据库上，那么offset就是10000，limit就是1000，第一条记录第一次开始配合获取0-1000，第二次分配获取10000-11000，依次类推。</p>
<p> 这里需要考虑一个问题，就是如果请求ID分发的服务的流量<strong>怎么路由</strong>到具体的记录呢？如果流量全部都请求到第一条记录上了，就会导致请求不均。<br>
 这个问题很简单，有一定开发经验的读者自然可以联想到用一致性hash去路由，具体路由的key可以根据业务去定，比如用户手机号。（具体一致性hash路由如何实现，可以参考利用treeMap实现）</p>
<p> 以上方案算是解决性能问题，但是还有比较致命的问题，就是无法横向扩展。就比如说现在有10台机器不同数据库，每一个数据库一条记录。假如现在有新的机器10台机器想要加入分配的话，那么就要修改offset和initial_id，所以在不停机实现的话，可能无法实现（目前笔者没有想到方法解决，如果读者有idea可以欢迎和我讨论）。这里笔者提供一种方法去解决：<br>
 提前预先分配100条记录，每一条记录一批次获取100个ID，offset设置为10000，当前10台机器每一台有10条记录，后续有新机器的话直接将记录不停机转移到新机器就可以了。</p>
<h4 id="22-redis序列化分发">2.2 Redis序列化分发</h4>
<p>Redis来生成ID，这主要依赖于Redis是单线程的，所以也可以用生成全局唯一的ID。可以用Redis的原子操作 INCR和INCRBY来实现。目前单台redis的qps能够达到5W，所以一定程度上能够解决性能问题。具体实现笔者这里就不阐述了。</p>
<p>当然用这个方案也有缺点：</p>
<ol>
<li>依赖redis，如果业务中没有就要依赖这个中间件</li>
<li>生成的ID是单调递增的，容易暴露系统的用户数</li>
</ol>
<h4 id="23-snowflake雪花算法">2.3 SnowFlake雪花算法</h4>
<p>以上2.1 2.2方案都能解决性能问题，但是产生的ID，是连续的，容易暴露自己系统中用户的数量。所以有些系统会要求要趋势递增，而且要保持信息安全。目前雪花算法就能解决这个问题。</p>
<p>其中原理就是：给一个64位的二进制数字，其中</p>
<ul>
<li>第1位置为0。</li>
<li>第2-42位是相对时间戳，通过当前时间戳减去一个固定的历史时间戳生成。</li>
<li>第43-52位是机器号workerID，每个Server的机器ID不同。</li>
<li>第53-64位是自增ID。<br>
<img src="https://zhangyaoo.github.io/post-images/1604663039402.png" alt="" loading="lazy"></li>
</ul>
<p>这个方案也有缺点：</p>
<ol>
<li>实现比较复杂，考验开发人员</li>
<li>需要独立部署实现</li>
<li>强依赖时钟，时钟回拨会有重复的ID</li>
</ol>
<h3 id="三-当前方案是如何做的">三、当前方案是如何做的</h3>
<p> 参考上述方案后，技术团队考虑到未来业务的增加，流量的增长以及后续的扩展，准备利用方案三去实现。其中具体实现可以参考笔者GitHub的实现：<a href="https://github.com/zhangyaoo/fastim/blob/master/fastim-leaf/src/main/java/com/zyblue/fastim/leaf/manager/SnowFlakeManager.java">分布式ID SnowFlake实现</a><br>
 当然使用方案三也会有缺陷，比如会发生时钟回拨问题，以及分布式ID分发服务强依赖zookeeper。</p>
<h4 id="31-时钟回拨">3.1 时钟回拨</h4>
<p> 发生时钟回拨的原因是，如果分发服务正在生成ID的过程中，系统时间因为不可抗拒的因素或者人为因素导致时间倒流了，会导致可能会有重复的ID生成，作为分布式ID分发这个是不准发生的。所以如果发生时钟回拨那么就抛出异常，实现如下</p>
<pre><code class="language-java">long timestamp = System.currentTimeMillis();
// 如果当前时间戳小于上次分发的时间戳
if (timestamp &lt; lastTimestamp) {
    long offset = lastTimestamp - timestamp;
    if (offset &lt;= 5) {
        // 如果时间戳间隔小于5，那么进行等待，等待窗口时间，然后再进行重试
        try {
            wait(offset &lt;&lt; 1);
            timestamp = System.currentTimeMillis();
            if (timestamp &lt; lastTimestamp) {
                throw new RuntimeException(String.format(&quot;lastTimestamp %s is after reference time %s&quot;, lastTimestamp, timestamp));
            }
        } catch (InterruptedException e) {
            logger.error(&quot;wait interrupted&quot;);
            throw new RuntimeException(String.format(&quot;lastTimestamp %s is after reference time %s&quot;, lastTimestamp, timestamp));
        }
    } else {
        // 如果相差过大，直接抛出异常
        throw new RuntimeException(String.format(&quot;lastTimestamp %s is after reference time %s&quot;, lastTimestamp, timestamp));
    }
}
// 如果等于，表明同一时刻
if (lastTimestamp == timestamp) {
    // 如果小于计数器最大值就，增加
    if (this.counter &lt; MAX_SEQUENCE) {
        this.counter++;
    } else {
        // 表明同一时刻，同一机器下，的所有计数器都用完了
        throw new RuntimeException(&quot;Sequence exhausted at &quot; + this.counter);
    }
} else {
    //如果是新的ms开始
    counter = 0L;
}
// 记录这一次时间戳，用作下一次比较
lastTimestamp = timestamp;
// 后续的生成ID逻辑
</code></pre>
<h4 id="32-强依赖zookeeper">3.2 强依赖zookeeper</h4>
<p>以上能解决时钟回拨的问题，但是强依赖zookeeper来生成分布式环境下的当前机器的ID。笔者参考dubbo的设计思想，当ID分发服务通过ID+端口注册到zookeeper的递增持久节点后，返回的节点直接存储再本地文件中，实现高可用，如下</p>
<pre><code class="language-java">/**
 * 高可用，防止zookeeper挂了，本地本机生效
 * 写入本地文件的时机：当前机器获取zookeeper的持久节点后
 */
private void writeWorkerId2Local(int workerId){
    String path = WORKERID_PATH + File.separator + applicationName + File.separator + &quot;workerId.properties&quot;;
    File file = new File(path);
    if(file.exists() &amp;&amp; file.isFile()){
        try {
            FileUtils.writeStringToFile(file, &quot;workerId=&quot; + workerId, false);
        }catch (Exception e){
            logger.error(&quot;e:&quot;, e);
        }
    }else {
        boolean mkdirs = file.getParentFile().mkdirs();
        if(mkdirs){
            try {
                if (file.createNewFile()) {
                    FileUtils.writeStringToFile(file, &quot;workerId=&quot; + workerId, false);
                    logger.info(&quot;local file cache workerID is {}&quot;, workerId);
                }
            }catch (Exception e){
                logger.error(&quot;e:&quot;, e);
            }
        }
    }
}
</code></pre>
<h3 id="四-采用分布式id上线后产生的bug">四、采用分布式ID上线后产生的BUG</h3>
<h4 id="40-问题分析">4.0 问题分析</h4>
<p>当上线分布式ID分发服务后，观察日志，出现大量的报错，如下：</p>
<pre><code>io.lettuce.core.RedisCommandExecutionException: ERR bit offset is not an integer or out of range
at io.lettuce.core.ExceptionFactory.createExecutionException(ExceptionFactory.java:135) ~[lettuce-core-5.2.1.RELEASE.jar:5.2.1.RELEASE]
at io.lettuce.core.ExceptionFactory.createExecutionException(ExceptionFactory.java:108) ~[lettuce-core-5.2.1.RELEASE.jar:5.2.1.RELEASE]
at io.lettuce.core.protocol.AsyncCommand.completeResult(AsyncCommand.java:120) ~[lettuce-core-5.2.1.RELEASE.jar:5.2.1.RELEASE]
at io.lettuce.core.protocol.AsyncCommand.complete(AsyncCommand.java:111) ~[lettuce-core-5.2.1.RELEASE.jar:5.2.1.RELEASE]
at io.lettuce.core.protocol.CommandHandler.complete(CommandHandler.java:654) ~[lettuce-core-5.2.1.RELEASE.jar:5.2.1.RELEASE]
at io.lettuce.core.protocol.CommandHandler.decode(CommandHandler.java:614) ~[lettuce-core-5.2.1.RELEASE.jar:5.2.1.RELEASE]
…………
</code></pre>
<p>乍看是redis的抛出来的错误，和这次分布式ID改造没有什么关系，但是仔细静下来想一想，这次ID改造是从原来的数据库自增改造的，数据库自增数据主键很小是int类型，然后用了64位二进制数据当作ID后，导致redis中用户的数据存不下去，然后笔者就按照这个思路去发掘问题。</p>
<p>笔者从业务抛出的堆栈中发现，这个错误是在判断用户是否是新用户服务方法中抛出的，而判断是新用户的逻辑就是，利用redis的bitmap来解决的：getbit new_user_key userId，其中 userId为用户ID，如果用户发生了交易信息，就会执行：setbit new_user_key userId 1 这个命令。 为什么要用bitmap解决呢，主要是因为如果从交易记录表查询某个用户是否交易信息来判断是新用户的话就会非常耗时，所以只要是发生了交易信息就设置bitmap就可以了。</p>
<p>那为什么会抛出out of range这个错误呢，我们知道bitmap底层其实就是String类型，而String类型的最大长度为512M，官网截图：<br>
<img src="https://zhangyaoo.github.io/post-images/1605157810715.png" alt="" loading="lazy"><br>
所以如果offset超过512M这个范围那么就会抛出异常，512M = 2^9 * 2^12 * 2^12 * 2^3 = 2^32 bit，也就是支持Integer类型的最大值，而我们这次分布式ID服务ID是64位的，支持2^64 bit，所以如果offset也就是userId大于2^32的话就会抛出out of range异常了。</p>
<h4 id="41-问题解决">4.1 问题解决</h4>
<p>找到了问题，也就好去做优化了，这里笔者提供几个方法作为参考</p>
<ol>
<li>在数据库用户表或者用户扩展表中增加一个字段，如果发生了交易，那么将字段标记为老用户</li>
<li>把用户ID放入redis集合set中，利用SMISMEMBER命令判断当前用户是否在集合内，当然这个会有性能问题，其方法时间复杂度位O(N)，官方截图:<br>
<img src="https://zhangyaoo.github.io/post-images/1605162870590.png" alt="" loading="lazy"></li>
</ol>
<h3 id="五-总结">五、总结</h3>
<p> 笔者从分布式ID选型出发，介绍了几种业界几种比较常用的生成方法，并且介绍了其优缺点，然后结合实际业务出发，选择合适的方案。然后介绍了使用SnowFlake算法导致的业务问题，以及分析最后提供解方法。从这次踩坑的经历来说，我们要懂技术体系，并且还要非常熟悉业务，最大程度避免功能之间的相互的影响导致的bug。</p>
<h3 id="六-参考">六、参考</h3>
<ul>
<li>美团分布式算法ID几种实现方式——https://tech.meituan.com/2017/04/21/mt-leaf.html</li>
<li>SnowFlake算法——https://github.com/twitter-archive/snowflake</li>
</ul>
]]></content>
    </entry>
    <entry>
        <title type="html"><![CDATA[SaaS系统多数据源路由优雅解决方案]]></title>
        <id>https://zhangyaoo.github.io/post/saas-xi-tong-duo-shu-ju-yuan-lu-you-you-ya-jie-jue-fang-an/</id>
        <link href="https://zhangyaoo.github.io/post/saas-xi-tong-duo-shu-ju-yuan-lu-you-you-ya-jie-jue-fang-an/">
        </link>
        <updated>2020-10-16T02:26:30.000Z</updated>
        <content type="html"><![CDATA[<h2 id="背景">背景</h2>
<p>在目前的SaaS系统中，业务开发者需要重点关注的一个问题就是数据隔离问题，这个是做SaaS系统必须要考虑的点，多租户数据隔离是每个SaaS系统都要遇到并且要解决的问题，笔者就分享下解决这种问题的思路、具体的解决方案以及优雅的解决思路。</p>
<h2 id="一-解决方案介绍">一、解决方案介绍</h2>
<h3 id="目前业界数据隔离方案">目前业界数据隔离方案</h3>
<p>1、独立数据库，通过动态切换数据源来实现多租户<br>
2、共享数据库，隔离数据架构<br>
3、共享数据库，共享数据表，使用字段来区分不同租户，此方案成本最低</p>
<p>以上方案从上到下，安全性逐渐降低。由于考虑到安全问题，故采用第一种方案解决数据隔离<br>
优点：</p>
<ol>
<li>非常安全</li>
<li>数据互不影响，性能互不影响</li>
<li>数据迁移，数据扩展方便</li>
</ol>
<p>缺点：</p>
<ol>
<li>需要维护大量的数据库</li>
<li>需要自行切换数据库，开发量多且实现复杂</li>
</ol>
<h3 id="具体技术实现">具体技术实现</h3>
<p><strong>简单的架构图</strong><br>
<img src="https://zhangyaoo.github.io/post-images/1603179800053.png" alt="" loading="lazy"><br>
如图所示，SaaS项目大概架构图，关键点是应用层传参，以及路由层的实现。</p>
<p><strong>实现</strong><br>
1、应用层：项目中应用service层是dubbo服务，而且项目分多层，这里需要考虑到多层服务场景下，如何优雅传参问题，如下图所示<br>
<img src="https://zhangyaoo.github.io/post-images/1603181882775.png" alt="" loading="lazy"><br>
我们考虑到租户ID是唯一标识，和业务参数绑定在一起不优雅，所以两种参数分开处理，业务参数直接参数透传，租户ID唯一标识通过隐式传参来处理（参考dubbo http://dubbo.apache.org/zh-cn/docs/user/demos/attachment.html），并且参数记录到服务本地的threadlocal中，以便后续其他业务需要。具体实现如下：<br>
<img src="https://zhangyaoo.github.io/post-images/1603183675071.png" alt="" loading="lazy"></p>
<p>2、路由层：路由层实现主要是自行实现spring框架中DataSource接口，自定义dynamicDataSource类，然后implement DataSource接口，实现getConnection方法。然后重新定义SqlSessionFactory的bean，将自定义DataSource类属性注入。<br>
<img src="https://zhangyaoo.github.io/post-images/1603183148592.png" alt="" loading="lazy"><br>
<img src="https://zhangyaoo.github.io/post-images/1603183156251.png" alt="" loading="lazy"><br>
然后我们只需要关注getConnection方法根据租户ID，选择相对应的租户连接池就可以了。<br>
如图中，我们只需要实现这个selectTenantCodeDataSource()这个方法就可以了，这个方法实现很简单，这里就不贴图了。selectTenantCodeDataSource()方法主要就是从threadlocal中拿租户ID，然后去缓存池map中拿出连接池信息。<br>
<img src="https://zhangyaoo.github.io/post-images/1603183509071.png" alt="" loading="lazy"><br>
其中，dataSourceCachePool是在初始化配置时候，将所有的租户连接池直接创建，然后扔到dataSourceCachePool。key是租户的ID，value是连接池信息。</p>
<p>具体的初始化配置：</p>
<pre><code class="language-java">/**
 * 初始化数据源
 */
@Configuration
public class DataSourceInit {
    
    @PostConstruct
    public void InitDataSource()  {
        log.info(&quot;=====初始化数据源=====&quot;);
        TenantRoutingDataSource tenantRoutingDataSource = (TenantRoutingDataSource)ApplicationContextProvider.getBean(&quot;tenantRoutingDataSource&quot;);
        Map&lt;String, DataSourceCache&gt; dataSourceCachePool = new HashMap&lt;&gt;();

        List&lt;TenantInfo&gt; tenantList = tenantInfoService.InitTenantInfo();
        for (TenantInfo tenantInfo : tenantList) {
            log.info(tenantInfo.toString());
            HikariDataSource dataSource = new HikariDataSource();
            dataSource.setDriverClassName(tenantInfo.getDatasourceDriver());
            dataSource.setJdbcUrl(tenantInfo.getDatasourceUrl());
            dataSource.setUsername(tenantInfo.getDatasourceUsername());
            dataSource.setPassword(tenantInfo.getDatasourcePassword());
            dataSource.setDataSourceProperties(master.getDataSourceProperties());
            dataSourceCachePool.put(tenantInfo.getTenantId(), dataSource);
        }
        //设置数据源
        tenantRoutingDataSource.setDataSources(dataSourceCachePool);
    }
}
</code></pre>
<h2 id="二-方案的隐藏缺点以及解决">二、方案的隐藏缺点以及解决</h2>
<h3 id="隐藏的缺陷">隐藏的缺陷</h3>
<p>相信有一定开发经验的读者应该能想到，上述方案最大的缺点就是性能问题，对MySQL有非常大的影响。因为一开始初始化非常多的连接池，就会占用连接资源，比如租户从100个扩展到了1000个以及更多，那么连接池数量就线性增长，如果一个连接池保持15个活跃连接的话，那么连接数就是15*1000，此时如果MySQL的maxconntion的数量非常小，那么MySQL侧就会抛出”too many connctions“错误，在应用层方面就是MySQL不可用了。<br>
没优化之前的架构：<br>
<img src="https://zhangyaoo.github.io/post-images/1603190851131.png" alt="" loading="lazy"></p>
<h3 id="解决">解决</h3>
<p>想保持数据库分离，又要考虑到MySQL性能问题，只能向连接池优化的方向去考虑，其实可以减少数量就可以了，这里实现方案就是一个数据库实例一个连接池，如下图所示：<br>
<img src="https://zhangyaoo.github.io/post-images/1603190889253.png" alt="" loading="lazy"><br>
具体实现就是将上述方案中的dataSourceCachePool的key改为 “IP+端口”，作为key。然后再数据源路由层，多一层映射（租户ID——&gt;数据库实例）就可以了。</p>
<h2 id="三-更优雅方案解决企业内部开发痛点">三、更优雅方案解决企业内部开发痛点</h2>
<h3 id="现状">现状</h3>
<p><strong>现状</strong>：企业内部项目组开发数据源路由，各个人员开发水平不一，各种路由方案实现不同，自己组内的开发的方案只能自己组内使用，并且实现复杂，耗人力物力。<br>
<strong>目标</strong>：项目组使用直接引入maven包，任何配置都不要配置（自定义的话需要自行在自己项目中配置属性），开箱即用。</p>
<h3 id="具体实现">具体实现</h3>
<p><strong>原理</strong>：直接采用springboot starter开发，将上述方案所有的逻辑和技术实现单独放入springboot starter工程中，采用外部配置的方式实现自定义配置。</p>
<p><strong>开发者实现</strong>：网上有许多springboot starter开发的流程和开发案例，笔者这里就只贴出关键的代码<br>
1、自动装配类：spring.factories中写入这个类DataSourceAutoConfigure，实现bean的自动装入，类里面主要是实现SqlSessionFactory和PlatformTransactionManager，然后在TenantRoutingDataSource的getconnection方法中自定义实现路由逻辑。</p>
<pre><code class="language-java">@Configuration
public class DataSourceAutoConfigure {

    @Resource
    private TenantRoutingDataSource tenantRoutingDataSource;

    @Bean
    @ConditionalOnMissingBean(SqlSessionFactory.class)
    @ConditionalOnBean(TenantRoutingDataSource.class)
    public SqlSessionFactory sqlSessionFactory() throws Exception{
        SqlSessionFactoryBean sqlSessionFactoryBean = new SqlSessionFactoryBean();
        sqlSessionFactoryBean.setDataSource(tenantRoutingDataSource);
        Objects.requireNonNull(sqlSessionFactoryBean.getObject()).getConfiguration().setMapUnderscoreToCamelCase(true);
        return sqlSessionFactoryBean.getObject();
    }

    @Bean
    @ConditionalOnMissingBean(PlatformTransactionManager.class)
    @ConditionalOnBean(TenantRoutingDataSource.class)
    public PlatformTransactionManager platformTransactionManager() {
        return new DataSourceTransactionManager(tenantRoutingDataSource);
    }
}
</code></pre>
<p>2、Java SPI机制：利用Javaspi 来获取用户自定义的mybatis plugin。这样做的好处是，不用每次增加一个plugin，就改动数据路由组件的代码。</p>
<pre><code class="language-java">public SqlSessionFactory sqlSessionFactory(@Qualifier(&quot;tenantRoutingDataSource&quot;) TenantRoutingDataSource tenantRoutingDataSource) throws Exception{
        SqlSessionFactoryBean sqlSessionFactoryBean = new SqlSessionFactoryBean();
        sqlSessionFactoryBean.setDataSource(tenantRoutingDataSource);
        Interceptor[] plugins = loadMybatisPlugin();
        if(plugins.length &gt; 0){
            sqlSessionFactoryBean.setPlugins(plugins);
        }
        Objects.requireNonNull(sqlSessionFactoryBean.getObject()).getConfiguration().setMapUnderscoreToCamelCase(true);
        return sqlSessionFactoryBean.getObject();
    }

    // SPI机制获取插件
    private Interceptor[] loadMybatisPlugin(){
        List&lt;Interceptor&gt; interceptors = new ArrayList&lt;&gt;();
        ServiceLoader&lt;Interceptor&gt; load = ServiceLoader.load(Interceptor.class);
        load.forEach(interceptors::add);
        return interceptors.toArray(new Interceptor[0]);
    }
}
</code></pre>
<p>3、dubbo filter扩展接口：获取租户ID，并且需要加@Activate注解，这样dubbo在初始化filter链的时候，自动将这个filter注册到filter链中，这样做的好处就是，用户在自己工程中不需要配置filter这个参数，无需增加任何的配置。</p>
<pre><code class="language-java">@Activate(group = {&quot;provider&quot;})
public class TenantCodeContextFilter implements Filter {
    @Override
    public Result invoke(Invoker&lt;?&gt; invoker, Invocation invocation) throws RpcException {
        String tenantCode = RpcContext.getContext().getAttachment(&quot;tenantCode&quot;);
        TenantCodeContextHolder.setTenantCode(tenantCode);
        return invoker.invoke(invocation);
    }
}
</code></pre>
<p>4、检查用户侧自定义配置是否正确：检查用户的配置是否合理，不合理的话再容器就绪阶段就会抛出异常</p>
<pre><code class="language-java">@Component
public class CheckConfigListener implements ApplicationListener&lt;ApplicationReadyEvent&gt; {

    @Override
    public void onApplicationEvent(ApplicationReadyEvent applicationReadyEvent) {
        ConfigurableApplicationContext applicationContext = applicationReadyEvent.getApplicationContext();
        ConfigurableEnvironment environment = applicationContext.getEnvironment();
        // 检查用户自定义配置是否正确，自行实现
        checkDatasourceConfig(environment);
    }
}
</code></pre>
<p>5、利用缓存池保存多个dataSource对象，一个MySQL实例对应一个dataSource对象，一个dataSource对应多个租户，而不是一个dataSource对应一个租户，这样的好处就是，如果一个MySQL实例里面的租户数据库过多，不会导致一个MySQL实例连接数膨胀问题。</p>
<pre><code class="language-java">    /**
     * 数据源缓存池
     * Key 一个MySQL数据库连接信息key
     * Value 缓存时RDS连接信息与DataSource
     */
    private final Map&lt;String, DataSourceCache&gt; dataSourceCachePool = new ConcurrentHashMap&lt;&gt;();
</code></pre>
<p><strong>用户使用</strong>：直接引入相应的maven，方便快捷</p>
<h2 id="四-todo后续优化">四、TODO后续优化</h2>
<ol>
<li>目前多租户数据源通用工程只支持Dubbo的调用，未来可扩展支持多种协议如HTTP、gRPC</li>
<li>目前只支持Hikari数据源，后续支持多种数据源类型，比如Durid</li>
<li>如果租户数据非常大，可以考虑空间换时间思想，使用缓存存放租户的数据源配置，提升查询效率。</li>
</ol>
<h2 id="参考">参考</h2>
<ul>
<li>SaaS系统数据隔离方案——https://blog.arkency.com/comparison-of-approaches-to-multitenancy-in-rails-apps/</li>
</ul>
]]></content>
    </entry>
    <entry>
        <title type="html"><![CDATA[MySQL联合索引在B+树的存储和查找]]></title>
        <id>https://zhangyaoo.github.io/post/mysql-lian-he-suo-yin-zai-bshu-de-cun-chu-he-cha-zhao/</id>
        <link href="https://zhangyaoo.github.io/post/mysql-lian-he-suo-yin-zai-bshu-de-cun-chu-he-cha-zhao/">
        </link>
        <updated>2020-06-29T09:32:43.000Z</updated>
        <content type="html"><![CDATA[<h2 id="前言">前言</h2>
<blockquote>
<p>在对MySQL开发中，联合索引是很常见的一种MySQL优化方式，本文解释了联合索引的存储以及查找过程，可以了解一下底层的原理以及加深对MySQL联合索引的理解。</p>
</blockquote>
<h2 id="innodb-b树">Innodb B+树</h2>
<p>先看一下Innodb B+树的主键索引和辅助索引。这里直接拿张洋大神的图：</p>
<ul>
<li>聚簇索引:<br>
<img src="https://zhangyaoo.github.io/post-images/1593425796639.png" alt="" loading="lazy"></li>
<li>辅助非聚簇索引:<br>
<img src="https://zhangyaoo.github.io/post-images/1593425801180.png" alt="" loading="lazy"><br>
<strong>结构</strong>：当一个表T（id,name,age,sex,high）建一个普通索引  KEY(name)，name的索引结果就和上面辅助非聚簇索引结构一样。<br>
<strong>查询</strong>：当有一个select id,name,age from T where name = &quot;&quot; 辅助索引会根据name在B+树上进行二叉树查找，找出叶子节点数据后发现没有age这个数据，就会进行<strong>回表</strong>操作到主键聚簇索引去查找，拿到聚簇索引叶子节点的age数据。</li>
</ul>
<h2 id="联合索引存储以及寻址">联合索引存储以及寻址</h2>
<ul>
<li>
<p><strong>索引结构</strong>：我们知道上述回表过程也会消耗性能，相当于多查一次，所以系统可以根据业务情况加上一个组合索引，当然并不是一直加组合索引就可以了，因为要考虑到索引存储空间的问题。例如给上述加上一个组合索引  KEY（name,age,sex）【 KEY（col1,col2,col3）】。那么这个组合索引的B+树非叶子节点数据结构和上述辅助非聚簇索引图一样，但是叶子节点是这样的：<br>
<img src="https://zhangyaoo.github.io/post-images/1593425790647.png" alt="" loading="lazy"><br>
叶子节点存储col1,col2,col3这三列数据以及加上ID这一列数据。</p>
</li>
<li>
<p><strong>寻址过程：</strong><br>
例如语句：select * from T where name = &quot;张三&quot; and age=25，先根据name字段从辅助聚簇索引定位到哪一个叶子节点数据中，然后根据age节点在上述表格的前6行中，寻找age= 25的数据，然后找出所有符合的数据以及其对应的ID，然后根据ID来进行回表操作查询。这里返回了三条数据，就回了三次表。<br>
上述回表过程中，笔者引入一个<strong>索引下推</strong>的一个功能，索引下推是MySQL在5.6版本后引入的一个查询优化。就拿上述的例子，在没有优化之前，据name字段查询“张三”后，会拿到6条结果，回表6次，然后从主键索引拿到6条数据后，根据age字段筛选数据；优化之后，先再辅助索引上面根据name字段和age字段筛选符合数据，也就是ID，然后再回表，这里回表了三次。</p>
</li>
<li>
<p><strong>组合索引注意事项</strong><br>
当然，联合索引的最重要的是注意联合索引的使用问题，要遵循最左匹配原则，才可以优化到整个SQL了。</p>
</li>
</ul>
<h3 id="总结">总结</h3>
<p>以上，总结了MySQL的索引的基本原理，以及联合索引的存储和寻址过程，并且引入索引下推概念，还有使用联合索引的注意事项。</p>
<h2 id="参考">参考</h2>
<ul>
<li>MySQL索引背后的数据结构及算法原理——http://blog.codinglabs.org/articles/theory-of-mysql-index.html。</li>
</ul>
]]></content>
    </entry>
</feed>