一Seata分布式解决方案TCC模式TCC模式理论TCC模式和AT模式很相似第一阶段都是独立事务执行完了直接提交不同的是TCC模式不用去加锁也不用生成快照因此性能上会更好TCC模式的第二阶段是基于人工编码的方式来实现数据恢复的不像AT是自动实现的人工编码的方式需要实现三个方法分别是tryconfirmcanceltry用来进行资源的检测和预留也就是说我需要修改某个资源的时候先把这个资源预留下来等到第二阶段的时候在对这个资源进行一个具体的操作cancel如果第二阶段需要进行回滚就执行cancelcancel是对预留资源的一个释放可以理解为对try的反向操作confirm完成资源业务操作这里要求t
2024-01-11 20:20 1010 0 分布式事务
前言在Online学习平台中当用户观看视频时用户离开再次观看时我们如何对上次的播放进度进行保存完成续播呢接下来就由我来揭开这神秘的面纱我参与了整个学习中心的功能开发其中有很多的学习辅助功能都很有特色比如视频播放的进度记录我们网站的课程是以录播视频为主为了提高用户的学习体验需要实现视频续播功能这个功能本身并不复杂只不过有如下要求首先续播时间误差要控制在秒以内而且要做到用户突然断开甚至切换设备后都可以继续上一次播放要达成这个目的使用传统的手段显然是不行的首先要做到切换设备后还能续播用户的播放进度必须保存在服务端而不是客户端其次用户突然断开或者切换设备续播的时间误差不能超过秒那播放进度的记录频率就需
大家好我是小蔡今天来总结项目一用户信息的传递这一模块前言总所周知用户信息在服务之间的传递方式这是一个老生常谈的问题了在我的在线教育项目中无论是用户购买课程还是后续对课程的学习等我们都需要保证用户信息在服务之间的传递的可靠性那么该从哪里获取用户信息呢实现思路Online学习平台是基于JWT实现登录的登录信息就保存在请求头的token中因此要获取当前登录用户只要获取请求头解析其中的token即可如果不熟悉可以看我上一篇文章总结登录鉴权怎么实现的httpcqkjavacnhtml登录鉴权怎么实现的但是每个微服务都可能需要登录用户信息在每个微服务都做token解析就属于重复编码了因此我们的把token
2024-01-10 17:06 1324 0 拦截器 过滤器 ThreadLocal
HashMap线程安全吗当然不安全了原因如下put方法中的非原子性操作扩容时的非原子性操作put方法中的非原子性操作在HashMap的put方法中会涉及到多个步骤包括计算键的哈希值找到对应的桶处理哈希冲突等这些步骤在没有外部同步的情况下不是原子的所以在多线程并发时可能会出现问题假设有两个线程A和B同时尝试put同一个键到HashMap中线程A计算了哈希值并找到了对应的桶线程B在线程A还未完成put操作时也计算了相同的哈希值并尝试修改同一个桶如果线程A在线程B修改桶之后才完成put操作那么线程B的修改可能会被线程A的操作覆盖从而导致数据丢失uploadfaffdaabddpng扩容时的非原子性操
前言我的项目一用户登录时基于JWT登录的如果有对JWT不了解的同学可以看我之前总结的这篇文章JWT令牌认证解析流程及如何使用httpcqkjavacnhtmlJWT令牌认证解析流程及如何使用下面我来结合项目中的代码总结一下项目中登录流程的实现登录login入口uploaddcbeceabafacecdebpng生成tokenjavaprivateStringgenerateTokenLoginUserDTOdetail生成accesstokenStringtokenjwtToolcreateTokendetail生成refreshtoken将refreshtoken的JTI保存到RedisSt
事务事务的概念事务指的是一个操作序列该操作序列中的多个操作要么都做要么都不做是一个不可分割的单位事务的四大特性原子性事务是最小的执行单位不允许分割事务的原子性确保动作要么全部执行要么全部不执行一致性执行事务的前后数据保持一致例如转账业务中无论事务是否成功转账者和收款人的总额应该是不变的隔离性各个事务的执行互不干扰持久性一个事务被提交后他对数据库中数据的改变是持久的即使数据库发生故障也不应该对其有任何影响事务的并发问题脏读事务B修改数据后回滚期间事务A读到的数据就是脏读uploaddbedbfaedcbpng不可重复读事务B修改数据导致事务A前后两次读取不一致uploadbbbadbcdcffb
2024-01-05 20:37 1425 0 Spring
