golfxiao的专栏

有了前两篇的架构演进后，有一个问题就紧接着诞生了，对于诸多业务方来说，关键数据源的迁移如何在各个产品落地？这是一个全局性的问题，需要统一考虑，否则之前看似合理的架构优化却可能因为对接时的实际困难而落不了地。

这篇文章我们以功能设置为例，继续讨论公共业务提取这个话题，讨论下这块业务在产品多元化的过程中出现的一些问题。

在产品业务多元化的过程中，往往会遇到一些与业务发展不匹配的架构问题，这些问题可能会在业务迭代中以性能差、重复开发等形式表现出来，进而给系统的扩展和维护带来一些挑战。

初次使用图数据库，拿不准性能究竟如何，想针对自己的业务场景做压测，又困于无法快速生成规模化的数据……

手动修改所有服务的代码去适配另一个数据库，不太现实，后期维护也是一个问题，于是就想能不能找一个统一的地方来处理这个适配工作。

DML语句的适配也可以简单分为两类问题：简单用字符串替换能解决的手动修改所有服务的代码去适配另一个数据库，不太现实，后期维护也是一个问题，于是就想能不能找一个统一的地方来处理这个适配工作。

sqlproxy是一个基于kingshard二次开发的用于信创数据库对接的中间件项目，致力于简化异构数据库的对接工作，目标是让现有基于MySQL的项目无缝迁移到其它类SQL型数据库，例如：Oracle、达梦。sqlproxy的主要工作是在中间件上对不同DB的语法和协议作转换，以便现有业务项目不改动或尽量少改动，使用原来的MySQL语法和驱动就能操作另一个信创数据库。

前一篇文章介绍了用来验证系统的正确性，那么验证完我们就直接用新版本替换掉老版本吗？

重构一个系统时会面临这样一种场景，当经过业务梳理、重新设计、代码重构等一系列环节后，发现最难的却是如何验证优化后系统的正确性。

业务链就是设计模式里提到的责任链，也有叫职责链，名字不关键，重要的是理解它能用来解决什么问题。代码开发如同赶路，在适当的时候需要停下脚步，分析下需求演变特点，看看前面的方向。

业界很多厂商有已经提供好的短网址服务，像百度提供的`https://dwz.cn/`, 但用下来存在几个问题：1. 访问百度API需要走公网，单次访问延时基本在200ms以上，会拖慢业务接口速度； 2. 生成的短链域名与企业主域名不一致，例如：dwz.cn 之于 quanshi.com， 没有相关性

上篇我们介绍了一个软件包在服务端的吃包和发布过程，这篇我们介绍差异化升级的主体流程。客户端的整个升级可以分为三部分：检测升级，请求差异包，本地文件替换

很多软件在使用过程中，都会自动弹出新版本提示，当我们点击“立即更新”后，就自动下载升级包走升级流程，这个升级过程往往比较快，不需要像第一次下载安装包时等那么久，其中最主要的区别就在于走了差异化升级

在一个活跃的APP背后，往往有一套默默无闻的服务器系统作为支撑。为了应对灾备和业务量波动，可能不只一套环境活跃，通常会有多套环境同时对外提供服务。鉴于下面一些实际情况，多套服务器的流量分配将会成为一个问题。为了满足上面这些需要，我们需要一些方法来调度流量，常见的方法有随机、轮询、按来源IP哈希等

个人认为这个案例的价值在于它体现了日常开发中一个很重要的思想：提取共性。试想，当遇到相似的需求，如果A做一遍，B又做一遍，C再做一遍，不仅开发时是三倍的人力花费，日后维护也是要浪费三倍人力，并且代码腐化臃肿，极易出现漏改，从而导致Bug和故障修复不彻底，又倒过来反复花费精力

抽奖中有一个比较典型的问题：重复中奖。抽奖往往不只一轮，在多轮抽奖下，如果之前中过奖的人接连继续中奖，这场活动会瞬间引来大家非议，主办方也会陷入尴尬，为避免把一场活动办砸，我们有必要解决下这个问题。

有这样一类场景，除了需要异步运行并等待结果外，还要求并行的任务不能太多，以免短时间内将资源用完，给系统其它业务造成影响。基于以上场景，我们就想，能不能给WaitGroup加一个授权数量限制limit, 授权数量之内可以正常起动并行任务，超出数量就阻塞等待其它任务运行结束，有空余的授权名额再运行。于是，就有了今天的主题：带数量限制的WaitGroup。

Go中异步处理很方便，只要go一下就能异步执行。但也很容易造成go使用的泛滥，进而给系统带来一些异常，如：当与一些启用了限流的系统打交道，控制不好很容易触发限流阀值，导致业务处理失败； 有些系统的性能不是很好，如果不加限制很容易触发资源报警，如CPU使用率100%，数据库变慢甚至卡死……

在业务开发中，唯一标识符（ID）非常常见，ID生成器主要用来为业务生成标识符，它需要确保生成的ID是唯一的，以免发生ID冲突。上面的算法都有它们各自的适用场景和规模，但不是很适合我们，我们想要的是一款简单、高效、稳定的ID生成器，本文就来介绍一下我们自己设计的、并在业务系统中大面积使用的一种ID生成方法。

但是关于批量生成数据始终没有找到合适的工具。网上搜了好多次，也包括在nebula论坛里咨询，了解下来目前行业现状如下：1. 目前业界做图DB性能压测大部分基于社交数据，典型的如ldbc的snb社交数据集2. 生成数据方面目前也只找到ldbc提供的批量生成社交数据的工具，包括nebula提供的压测工具nebula-bench, 也是基于ldbc工具来生成数据；

日常工作中短链用的是比较多的，短链中最重要的一个组成部分是ukey，类似链接最后的4oZMbgcWl。鉴于以上需求，我们就在想，能不能设计一种ukey算法不仅能满足目前已知的Case，还能给后面的扩展留有一定的余地？

前几天听一位客户端同事报Mac上切换网络时会出现假连接现象，需要服务器配合调整心跳策略，以减轻对用户的影响。听到这个现象挺好奇的，原因在于：据同事描述，有些切换网络的场景应用层是监听不到事件的，导致连接没有走重连逻辑。那具体什么场景监听不到呢？我主要测试了两个场景：前一个场景未发现问题，第二个场景复现了问题：当我从家里的wifi “一朵霸王花" 切到 手机热点”nova 7 SE 5G“时， 对应云会议的IM中出现了一个端发消息另一个端收不到的Case‘：*说明：上面第一个图是手机端在12:00发送了7

问题描述DBA在群里报产线DB有故障，数据库所在机器的CPU使用率高达95%， 短时间内报了500+条慢查询，其中出现最多的是下面一条SQL语句：产线出故障时，运维同学一般都是描述现象，一个现象要转换为可以具体排查的问题，往往需要做一些信息的确认和提取工作的。就这个问题来说，CPU占用率高是现象，DBA帮我们做了第一步的信息提取：发现一条慢SQL。但是这个问题还不够具体，比如：究竟是不是这条慢SQL导致了CPU高是需要确认的，另外这个慢SQL究竟有多慢也不知道，所以研发还需要做进一步的信息提取。

最近产线环境偶发会出现用户收不到别人给他发送的IM消息，同事邀请我一起排查，现象是：他们的连接状态看着正常，自己能发送消息，但是收不到，退出重新登录能恢复，而且每次出现都是一大批消息，问题挺严重。知识铺垫在问题展开之前，有必要先介绍下公司的IM消息收发模型消息服务投递消息到指定的mq队列上； 每台长连接服务，从一个指定的mq队列上消费消息； 长连接服务维护了具体的终端连接池，拿到消息后，从池子里找到消息要投递的终端连接，通过网络IO将消息推出去； 客户端收到消息数据后，解析并显

整场会议的所有心跳请求都被阻塞，所以内存只升不降，接口大量60s响应超时，压测机被超时请求阻塞，最终表现为TPS很低；