- 博客(7)
- 收藏
- 关注
RSS订阅
原创 解决在实际业务中频繁持久化数据库问题
在惯性思维的情况下消息早期的持久化逻辑我是这样实现的。在这里会出现性能的问题就是第3点，如果用户在极短暂的时间内发送大量的消息，那么每一条消息都会进行持久化的操作并且还会频繁的提交事务；之前提到过主要是解决用户“在极短暂的时间”内发送大量的消息，避免，这个大量的消息频繁持久化到数据中而降低数据库性能，所以，这里可以将持久化停顿的时间间隔设定为非常短的一个间隔，目的只为了解决将短时间之内频发持久化大量消息，只需要在短暂的时间内批量持久化这一范围的消息即可，并且这里引入了重试机制解决临近消息持久化问题；
2024-02-21 11:28:54
1205
原创 解决缓存与数据库同步下的同步锁问题之分段锁
这里从业务逻辑上来说用户B请求的线程不应该被阻塞，因为用户B查询的是资源ID为2的数据，并不会跟用户A线程请求的资源ID为1的数据冲突，但是是通过同步锁时我们无法将锁的细粒度更小化；初看之下逻辑看似并没有什么问，但是，细心的人已经发现问题所在了，首先就是缓存为空判断这里，如果，缓存为空的情况下用户请求的线程会进入数据库代码块，由于同步锁的存在所以此代码块只能同时只能被一个线程所持有，那么后续请求的线程将会阻塞，直到第一次获取到的线程释放锁，那么后续的线程就会被唤醒开始竞争锁；
2024-02-04 11:25:17
1080
1
原创 同步分段锁在实际开发中的应用之：缓存击穿
延续上篇业务功能需求，上篇是计算项目的费用之后需要将费用持久化到数据库中，后续的同时会利用该费用数据来拼接各种各样的字符提示，最后将拼接完的字符存储Redis缓存中，后续的通过请求只需要查询缓存即可，免去之前拼接大量字符的性能开销；那么该流程就应该如下图所示这里使用读写锁和双检机制来确定性能的并发，读写锁的目的，读读允许、读写互斥。保证多个请求情况下的数据安全；双检机制是用来确保后续阻塞的请求不会重复执行查询数据库的操作避免缓存击穿。
2024-02-20 10:41:58
715
原创 同步分段锁在实际开发中的应用之：避免项目费用重复计算
因为，在锁住代码逻辑块这里必要要考虑到访问不同的项目ID时的情况，只有在访问在同一个项目ID时才会锁住；如果使用的是同步锁时锁住则是所有项目这样一来由于锁的细粒度不够就会导致锁住所有的项目，而不是根据不同的项目ID来锁住，实际的需求应该需要将锁下沉一层，分划成更小的细粒度。这里就需要使用分段锁来针对不同的项目ID来进行加锁，如果，请求访问的是同一个项目ID才会进入锁，如果，访问的不是同一个项目ID的话还是按照正常的代码逻辑执行。2、判断当前的用户请求携带的项目ID是否计算过费用。
2024-02-19 10:47:07
435
1
原创 同步分段锁在实际开发中的应用之：使用对象池优化锁效率
但是，对于一些已经使用过的且后续也不会再使用的锁对象，如何保证能够有效的释放这些锁对象了（避免无效对象占用内存）？3、Google Guava-LoadingCache，利用Google Guava提供的LoadingCache来实现分段的锁的内存池；2、LFU-使用频率最少内存淘汰算法，如果数据在某一段时间内使用的频率很小，那么也就意味着在未来的的一段时间内使用的频率就会更少（1、LRU-最近最少使用内存淘汰算法，如果数据最近没有使用过，那么也就意味着在未来的一段时间里也不会被使用（
2024-02-18 16:48:10
386
原创 利用Mybatis拦截器实现自定义的ID增长器
原生的Mybatis框架是没有ID自增器，但例如国产的Mybatis Plus却是支持，不过，Mybatis Plus却是缺少了自定属性的填充；例如：我们需要自定义填充一些属性，updateDate、createDate等，这时Mybatis Plus自带的ID自增器就无法满足需求；这种时候我们就需要自定义的ID增加器，可以自定义ID增长策略同时还得支持更多的属性自定义扩展，当然，最好能做成插件形式为其他项目或者模块提供引入那就更新好了。在开始之前我们先确定和分析主要的需求，了解了需求才能更好的制作。
2024-01-30 11:07:07
949
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人