自定义博客皮肤VIP专享

*博客头图:

格式为PNG、JPG,宽度*高度大于1920*100像素,不超过2MB,主视觉建议放在右侧,请参照线上博客头图

请上传大于1920*100像素的图片!

博客底图:

图片格式为PNG、JPG,不超过1MB,可上下左右平铺至整个背景

栏目图:

图片格式为PNG、JPG,图片宽度*高度为300*38像素,不超过0.5MB

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+
  • 博客(4)
  • 收藏
  • 关注

原创 springboot基本应用开发的脚手架。

gitup上自己弄的springboot基本开发的脚手架,具体功能实现参考md文档。

2024-12-22 15:29:24 207

原创 超卖问题为什么会出现以及解决超卖问题的几种方案

解决超卖问题是高并发系统中的关键任务之一。数据库事务隔离级别:使用串行化隔离级别来确保数据一致性,但会牺牲性能。悲观锁:通过行级锁防止并发访问库存,适用于并发较低的场景。乐观锁:通过版本号检查来避免超卖,适用于高并发但能容忍少量失败的场景。分布式锁:在分布式系统中使用 Redis 等分布式锁来同步库存操作,确保跨服务的一致性。每种方法都有其适用的场景,选择合适的技术方案可以有效地避免超卖问题,保障系统的稳定性和一致性。

2024-12-15 20:42:28 1315

原创 如何设计更巧妙的表来实现对帖子评论和对评论的回复以及类推的无限回复的问题呢。

我们则可以通过判断postId和answerId那个不为null来判断这个回复是对帖子的评论还是对消息的回复。当有一个论坛类项目,少不了的就是发帖子和评论帖子,以及对评论的回复。以及类推的无限回复问题。当获取评论的回复的时候我们就可以把这个用这个answerId来获取评论的全部回复。我们该如何巧妙的设计表来解决这个问题呢,其实很简单。我们同时引入了post_id和answer_id。对于回复的表我们的设计则更加巧妙。对于帖子表我们可以如下图来设计。这样就解决了无限消息问题。这样当前端传来一个请求体。

2024-12-14 20:10:18 168

原创 如何解决消息的独立性,确保用户在删除消息或撤回消息的时候另一方用户不受影响。

但是当我们有一方删除或者撤回消息的时候,如果按照正常的思路来删除的话,可能会让另一方也看不到消息,这显然不是我们想要的结果,因此我这里引入了Redis来存储两者的消息内容,当然也有别的思路,例如在上表中引入一个消息状态status 然后在引入一个新表把消息id和用户id穿进去,然后先判断消息状态,如果消息状态不对,就去这个表中找到底是两方的那个用户删除了消息,然后返回数据的时候不返回这个数据就行了。如原本用户1和用户2之间的消息,那当用户1获取和用户2消息内容的时候,要返回用户1和用户2之间全部的消息。

2024-12-14 19:48:11 653 1

空空如也

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

提示
确定要删除当前文章?
取消 删除