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 较高的服务进行完整性压测