零散获取的技术

数据方向:

 

打点->接口发kafka->整理到宽表->clickhouse分析型数据库 (因为数据是连续的,长度固定)

consul服务注册和发现  和zookeeper,eureka,etcd差不多
mqtt消息可以有一个回执
大量机器点对点tcp的实现  1000-1device服务
gdb -p pid;info threads; thread apply all bt; bt;
线程不断增长, mqtt client建立后没有正常销毁

-------------------------------------------------------------------------

0.任何服务容器内起不来的问题， 登录上去手敲换个端口运行，查看终端报错

 1.我们c端业务的线程用到从库,卡主主业务,所以都会有问题; 应该一个大屏从库可以爆掉,另一个是业务从库，现在没有的;

2.SELECT count(xc_ebike_user_orders.`orderId`) AS order_sum, ifnull(sum(xc_ebike_user_orders.cost) / 100, 0) AS order_amount_sum ,
FROM xc_ebike_user_orders 
WHERE xc_ebike_user_orders.`createdAt` BETWEEN '2021-12-13 00:00:00' AND '2021-12-13 23:59:59' AND xc_ebike_user_orders.`serviceId` IN (1, 7, 101, 114, 172, 188, 203, 216, 270, 610, 716, 718, 717, 1187, 719, 1556, 1704, 1703, 2062, 2057) 

 注意一下key_len的作用, key_len是5, 说明用到了前两个字段service_id, isPaid, 而cost又在结果集里面, 这可能是为啥要走idx_serviceId_isPaid_cost索引,不走createAt索引的原因;

可以的改法是 group serviceId having  serviceId` IN; 逼着serviceId不参与缩小结果集;

3.redis禁用keys ，后怎么模块搜索key，顺序取1000条，然后用返回的游标迭代取，初始游标是0

SELECT db
SCAN 0 MATCH *apscheduler* COUNT 1000 

4.长连接监听，nacos长连接监听线程，timeout时间里面有变动则有反馈，否则卡主时间到了返回空，不断的轮询但是又减少请求的次数

5.有条件的唯一索引实现：利用组合唯一索引中如果有null则失效的特性，主动加一个字段，让它需要重复的时候为null，需要唯一的时候传0