今天刚联系北京的维修站，说还没有固件，北京的还得再等等了。

如果要了解概念，可以看一下 wiki： https://en.wikipedia.org/wiki/Code_coverage
针对你的问题：
1. 实际落地一般经常看的有行覆盖率，函数覆盖率（好统计，容易提升），分支覆盖率，例如以前百度 C++模块要求 80%行覆盖率，60%分支覆盖率（时间长了，记忆不一定准确）。有工具可以统计出来，基本思路就是对代码插桩。
2. 自动化跟代码覆盖率没有关系，无论手动测试、自动化测试，亦或者是单元测试、接口测试、集成测试都是可以获取覆盖率的。
3. 接口自动化覆盖率应该是自己定的一个概念，互联网服务以 http 形式的 API 居多，相对独立。如果这个接口有一条或者多条自动化测试用例覆盖，那就接口覆盖了。跟代码覆盖率不是一个概念。至于需求覆盖率，应该类似，很少听到这种提法。

补充一点：覆盖率不能表示测试覆盖的完备性，只是用来指导如何提高提高测试覆盖完备性的手段。

@rihkddd 感觉加上阈值优化，都不需要字典树，直接 hashmap 都没问题。

@Mohanson 终于有人说字典树了，传统数据结构还是还高效的。可以做一些简单优化，比如定一个远低于 top10 的词频的阈值，去掉长尾数据，放到内存根本都不要 1 个 G 。
各种查询调节，分别建立对应的字典树。可以满足实时性和准确性。

# 转发脚本内容 tcpproxy.sh
----------
#!/bin/sh
# TCP Proxy using IPTables
echo 1 > /proc/sys/net/ipv4/ip_forward


# Flush nat table
iptables -t nat -F

# tcpproxy LOCAL_IP LOCAL_PORT REMOTE_IP REMOTE_PORT

function tcpproxy {
iptables -t nat -A PREROUTING --dst $1 -p tcp --dport $2 -j DNAT --to-destination $3:$4
iptables -t nat -A POSTROUTING --dst $3 -p tcp --dport $4 -j SNAT --to-source $1
iptables -t nat -A OUTPUT --dst $1 -p tcp --dport $2 -j DNAT --to-destination $3:$4
}
------------

# 使用方法
tcpproxy.sh 192.168.1.1 12345 192.168.1.2 12345

学习了，两点建议：
1. 使用统一的性能测量方式，文中有时候是平均值有时候是 p95，如果对性能比较敏感应该用比较严格的标准比如 p99.
2. 量化每一个优化措施的收益。

如果单纯的想快，最好用已经写好的矩阵计算库，不止并行会影响计算速度，例如缓存命中，算法，指令优化带来的提升都会很大。
如果你论文研究的就是矩阵计算，应该对上述问题都有了解，简单来说矩阵计算基本上没有 IO 。

@jorneyr 很标准的流程，就是可能需要在业务表里面维护一下消息的状态～

@GGGG430 不是的，事务就是 mysql db 的事务，数据是写的业务数据。你说的实现看起来没问题。要讨论的是仅把写数据和发消息两个操作放到一个 db 事务中的做法，能否达到预期效果。

@zczy 是的，去哪儿的 qmq 就是这么个思路实现事务消息特性的。

@zczy
@zpfhbyx
@coyove
@hun2008hun
感谢各位的回复，从你们的回复看，放到一个事务的做法应该是不对的。

@sch1111878 用的公有云，没法放机房，单独采购一个别的云服务，估计流程挺麻烦的，先不考虑了。

@Mrcocoa 就是看的这个项目，类似的项目也看过了，在 CentOS7 上时间安装不成功，感觉是网络的问题，导致 OSX 启动的时候无法联网、无法验证，安装不了。

@bleepbloop 实践过吗，速度怎么样？我试过，中间也遇到不少问题，还没走通。

看一下这个： http://websocketd.com/ ，websocketd --port=8080 your-program 就开了一个 websocket，前端脸上之后把终端的输出格式化一下展示就行了。

最近正好看到一个文章： https://testing.googleblog.com/2019/11/code-health-respectful-reviews-useful.html，应该可以回答一部分你的问题。

coverity 是 C/C++语言里面比较强的静态检查工具了，百度用的就是这款。

如果你已经确定了是 GC 导致的 CPU 占用，问题其实是要找内存泄漏点。可行的方法，使用 jcmd 统计堆内对象计数（先把问题复现），主要关注排名靠前的自己代码中 new 的对象，基本然后关注一下 new 这些对象的地方，基本上大概可以确定。还不是很确定可以用 idea 调试，关注上述代码逻辑，看是不是持续的，idea 调试的时候有窗口可以看到对象计数，占用内存大小。调试下来基本上都能找到问题点。