做茶评的网站,建设公司网站需要准备哪些材料,福建省建设工程信息网站,网站编辑教程订单宽表数据不同步
事情的起因是专员在 ze app 上查不到订单了#xff0c;而订单数据是从 mysql 的 order_search_info 查询的#xff0c;order_search_info 表的数据是从 oracel 的 BZ_ORDER_INFO 表同步过来的#xff0c;查不到说明同步有问题
首先重启#xff0c;同步…订单宽表数据不同步
事情的起因是专员在 ze app 上查不到订单了而订单数据是从 mysql 的 order_search_info 查询的order_search_info 表的数据是从 oracel 的 BZ_ORDER_INFO 表同步过来的查不到说明同步有问题
首先重启同步数据问题解决然后查找原因。首先看日志有如下两种情况
有的容器消费消息的日志正常打印 有的容器很长时间没有消费消息的日志看着像是消息丢失福华找dba确认后明确发送没问题只能是消费的问题
接着看容器的状况 查看了应用重启前各个容器的 CPU 和内存情况发现并不均匀有如下三种情况
CPU一直很高内存稳定CPU和内存一直稳定上升CPU一直很低内存稳定 看监控发现消息在分区中分布的也不均衡
接着就按照如下现象来进行排查问题
为什么消息发送不均衡为什么有的容器CPU一直很高有的一直很低有的持续升高CPU飙高的机器内存也不断上涨
为什么会出现这些现象
producer发送消息和consumer消费消息都有对应的负载均衡策略既然消息发送不均衡只需要看producer的负载均衡策略即可 producer的负载均衡实现类为 DefaultPartitioner具体实现为
如果 key 为 null消息将以轮询的方式在所有可用分区中分别写入消息如果 key 不为 null对 Key 值进行 Hash 计算从所有分区中根据 Key 的 Hash 值计算出一个分区号拥有相同 Key 值的消息被写入同一个分区
所以推测 hddp-datasync 消费的消息指定了key看消费日志确定了猜想key的名字为表名例如
HLASSET.BZ_ROOMCONFIG_DETAIL HLASSET.BZ_ORDER_INFO
这样就明确了同一张表的数据只会被发送到同一个分区同一个分区的数据只能被一个 Consumer 消费
接着我们查到 CPU 一直比较高的容器消费的是合同表的数据合同表的数据变更比较频繁所以CPU比较高
而 CPU 持续飙升的容器消费的是订单表的数据。
接着就是排查消费订单表的容器为什么CPU和内存持续飙升
排查内存泄漏
一般使用 Eclipse Memory Analyzer 分析内存泄漏的问题先生成 dump 文件 点击 Leak Supects 查看内存泄漏分析 总共使用了110MB内存Thread线程占用了29M总共创建了2686个线程看一下这些线程是哪些 线程数量最多的线程名字为datasync-execuotr-1到代码中查看是否有类似线程 每消费一次订单表的数据就会新创建一个线程池核心线程数为10不断创建线程导致内存和CPU不断飙升消息不能正常消费后续消费消息改成使用一个固定的现成池后消息正常消费
