【问题梳理】

最新推荐文章于 2024-11-03 16:03:04 发布

陈卓410

最新推荐文章于 2024-11-03 16:03:04 发布

阅读量109

点赞数

文章标签： redis 缓存 java

本文链接：https://blog.csdn.net/dream410/article/details/130995311

版权

问题梳理

难点：设备的命令的不确定性；设备的不稳定性。比如开门不发指令，心跳的自我保护机制

难点：设备的一些网络状态、命令的不稳定性

多次查询，如果多次都没有结果，把订单的仓门状态设置为异常，并通知运营人员。

补货员补货的时候发现有不属于我们的商品，把这个仓门这段时间所有订单拿出来核对，并通过监控探头核实。

金额小就打电话，金额大就报名。

有的是视觉柜，可以规避这种风险，但设备成本较高。

首先，肯定是会扣钱的，因为1货道的重量减轻了
那2货道，如果一个订单完成后一个货道的重量大幅增加，那我们就会把这个货道报警，通知运营人员去现场看一下，或通过摄像头看一下；或者客户自己发现没拿东西扣款了，会去我们的平台申诉。根据客户提供的照片信息，和缓存的重量信息，摄像头，考虑是否对其退款

用Redis做缓存，缓存设备信息
- [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-q0TPODXN-1685621626840)(C:\Users\Chen_Zhuo\AppData\Roaming\Typora\typora-user-images\image-20230529234502902.png)]
开仓门下单的时候，利用Redis做分布式锁。同时补货、换品也用的是这同一把锁
reddision 框架，watch dog机制
存阿里的APPKey和项目的配置信息
通道服务连的哪些设备
- 通道服务id sn1 sn2 sn3

分为强一致性和最终一致性
app创建用户下单信息 --> 账户服务创建账户信息（Seata AT）模式
最终一致性，结单的时候（RocketMQ的事务消息）
- [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-gy7Q2qNK-1685621626842)(C:\Users\Chen_Zhuo\AppData\Roaming\Typora\typora-user-images\image-20230530220650720.png)]

如果一个客户拿了东西，我们却没扣钱；

过去，只会在补货的时候运营人员才会发现；
每天晚上12点，或者交易量小的时候，凌晨1点也好2点也好；
去比较一下，每90s上传一次重量，最新的总重量去除以最新的单重=最新的库存，和数据库中的现有库存进行对比

如果是对的就没问题，如果对不上，通过之前重量更改的信息，然后打电话给客户能不能把钱补上，如果对方不补就算亏损。

做过。
- 最初通信服务100台，新生代老年代
- 后来通信设备越来越多，到了600台，持续发心跳导致新生代的Eden区压力越来越大
- CPU处理速度变慢
- 或导致频繁的full GC
怎么解决？
- 首先把每个通信服务我们最多让它连接300台~500台设备，新增的设备连到新的通信服务上。
- 通信服务做了集群，一共4~5台，缓存记录了每台设备连接的是哪些通信服务
- 正常情况下，老年代 : 新生代 = 2:1 将其调成老年代:新生代 = 1:1
- 再将新生代的 Eden : Survivor : Survivor = 8 : 1 : 1 改成 Eden : Survivor : Survivor = 3 : 1 : 1

大部分的JVM调优，都是调堆里面的新生代和老年代的比例，还有新生代 Eden区和Survivor区的比例。还有一个就是大对象的阈值。