02 2023 档案
摘要:1. 先用jps命令查出java进程号 2. 使用top命令查出该进程使用cpu最高、占用内存最大的线程(嫌疑最大) 这里我们选取微服务项目中的主进程24240 top -Hp 24240 -d 1 -n 1 3. 将该线程号转为16进制(线程号的显示用的是16进制) 24240 = 5EB0 4.
阅读全文
摘要:先分mysql 查询分析器,查看是否命中索引,然后把or like这种先排除,再不行了看看是否能走大数据层面,把数据聚合成es,再不行了,用到redis,ds这种内存索引,再不行就要去继续查找sql,总而言之就是使用各种索引,尽量避免全表查询
阅读全文
摘要:会记录当前缓存的时间,定义缓存失效时间,当表粒度的发生变更时,就会记录下来,并在使用缓存前先判断
阅读全文
摘要:发送消息 打断点能进入 监听接收消息这里打断点,发现没有消息接受 支付结果监听这里没有消费者在监听 检查交换机是否和队列已经绑定 排查代码 声明交换机 支付结果和交换机绑定
阅读全文
摘要:监听队列,如果队列不在要创建 因为是广播模式,要把交换机和队列绑定
阅读全文
摘要:公司的一个接口用redis存储pv/uv,一直以来,非常好用,某天发现,接口反映非常慢,经过长时间排查。是redis的cpu非常高,到了60%以上。之前设置的70%报警。然后有个广告使用了keys 查询,我们的redis 里面的key 有几千万,致使 cpu 超高。 改造这个方法后,速度明显起来了,
阅读全文
摘要:3秒到了时间就会释放锁,但如果一个程序执行需要花5秒,就会导致第一个请求把第二个请求的锁给释放掉,产生误删现象 自己只能释放自己的锁 防止恶意删除锁或者误删锁
阅读全文
摘要:热点key过期,加一个锁,抢占到锁才会去查询mysql数据库,然后查到数据后重新写入redis, 几百台服务器,几十个热点数据,不能用jvm锁 重试问题 重试了几次,库存就会扣减几次 一定要有else机制才行 从递归调用到while循环 一直尝试获取锁,获取锁之后,开始执行下面的try 不停的cas
阅读全文
摘要:不加锁的情况下,redis仍然没有正确的减少库存 用watch监听一个或者多个key的值 ,值不能发生变化,发生变化事务就会取消 开启watch后 数据并未变更,执行事务成功,事务需要先入队列queue,再按顺序执行 使用excu的时候需要new一个匿名内部类,里面的operations包含 red
阅读全文
摘要:1.jvm锁较为垃圾,无法解决服务外部的共享资源的并发性问题, 所以尽量不要选择jvm本地锁. 2.一个for update的sql语句使用 适合商品只有一个库存的时候 3. 先查询再更新的情况,一个sql无法满足业务需求,同事要记录数据前后的变化量时, 需要用到悲观锁和乐观锁 4.如果读要求高,优
阅读全文
摘要:乐观锁,例子,set count = 4997 ,version++,where id = 1 and version = 0 使用代码进行乐观锁操作 如果影响条数为0,则递归重新调用 数据库连接超时问题,加了事务后,在更新操作枷加锁,不停重试,导致阻塞无法连接 不加事务的情况下,更新操作,自己也有
阅读全文
摘要:书写顺序 SELECT -> DISTINCT -> FROM -> JOIN -> ON -> WHERE -> GROUP BY -> HAVING -> ORDER BY -> LIMIT 执行顺序 FROM -> JOIN -> ON -> WHERE -> GROUP BY -> HAVI
阅读全文
摘要:不需要加锁,一行更新语句即可,符合原子性 对于没有加注解的,mysql也会对增删改的自动加上事务,autocommit =0 的时候才没有事务,其他都有事务开启 sql语句可以解决 集群,多例和事务三种问题,但是在单一仓库才可以,如果多仓库上海,北京, 里面有相同的商品编号,就会出现新的问题 使用行
阅读全文
摘要:感觉框架改动了,应用上没法感知,只有使用过程中发现问题才能去发现。 上午的这个问题是因为多数据源 事务的问题引起的,在不引入其他组件的情况下,在1.0下也是会存在这个问题(我已在菱信的项目中尝试了),只不过在1.0下我们这种写法或使用场景比较少没有发现;现阶段只能尽量避免这种使用方式,因为本身这种使
阅读全文
摘要:java自己的 synchornized 和 lock锁都是悲观锁,默认一定有其他线程争抢并修改数据 乐观锁 默认没有别的线程来抢夺,修改数据 更适合读多的场景, 通过version控制版本号,活着cas算法 超卖问题 超卖问题,本质是第一次发送了100条查询请求,查到的都是5000条, 然后都符合
阅读全文
摘要:多实例提供服务, p1,p2,p3 提供的服务是一样的,但是地址不一样 基于tcp封装的rpc的调用模式 dubbo使用的是rpc,基于tcp协议开发,效率是高于springcloud的rest,基于http协议的 dubbo的容错策略:
阅读全文