6月11日
第一次发版，配合运维解决线上环境问题。
操作步骤：
wget https://ftp.gnu.org/gnu/gcc/gcc-9.1.0/gcc-9.1.0.tar.gz
sudo yum install libmpc-devel mpfr-devel gmp-devel
sudo yum install zlib-devel*
tar xf gcc-9.1.0.tar.gz
cd gcc-9.1.0
./configure --with-system-zlib --disable-multilib --enable-languages=c,c++
make -j24
sudo make install
export PATH=/usr/local/bin:$PATH
export LD_LIBRARY_PATH=/usr/local/lib64:$LD_LIBRARY_PATH
6月12日
服务器扩容，新增2台机器。
新增机器之后，开放 CPU 限制导致，由于 login 消息积压，导致 CPU 一直满载。
ncpu := runtime.NumCPU()
if ncpu > 2 {
runtime.GOMAXPROCS(int(ncpu) - 2)
}
MQ 消费问题，如何能更自然的解决积压问题，还有积压告警
问题：
如果没有消费者，生产者持续生成，数据会存到硬盘，过期策略，等到消费者上线会产生积压，要是新增一个消费者，之前的数据怎么搞，那不是都有积压，哈？
6月13日
四台机器消费能力正常，增加大数据提供的线上接口之后出现另外的问题，机器有16G的内存，基本一小时内打满。
分析原因是当前版本 resty 的遗留问题，针对类似参数多变的 URL 会进行 Metric 监控采集，由于 QPS 晚高峰达到 5000+ 情况下，大数据接口产生数据延时以及报错，导致 timer 时延进而内存堆积。
image.png
升级 resty 解决。
增加自定义 Metric
func SetMetric(typeStr string) {
EncryptImp.metric.Counter(typeStr, map[string]string{
"ctype": typeStr,
}).Inc(1)
}
服务上线前对大数据的接口没有进行压测，线下没发现这个问题。
调整之后目前线上服务稳定。
总结
- MQ 消费服务上线注意积压问题，准备解压方案
- 对于 QPS 较高的服务进行完整性压测
