• 「黑马点评」五、分布式锁优化

    基于 SETNX 的分布式锁问题 不可重入:获得锁的线程可以再次进入到相同锁的代码块中,意义在于防止死锁,如在锁内调用另一个带锁的,产生死锁 不可重试:没有重试机制,才获取一次就返回 false 超时释放:锁然避免了死锁,但是如果是业务超时,锁自动释放,可能的额外风险 主从一致性:如果使用 Redis 的主从集群,因为异步同步,可能会出现主节点宕机,数据未同步 Redisson 入门 Redisson 是一个在 Redis 的基础上实现的 Java 驻内存数据网格(In-Memory Data Grid) 提...

    2025 年 4 月 23 日 星期三
    8
    阅读全文
  • 「黑马点评」四、分布式锁

    分布式锁 产生背景:各自单机看各自的锁监视器却无法共享锁 image.png|500|500 不用 JVM 内部的锁,使用一个,满足分布式系统或集群模式下多进程可见且互斥的锁,即分布式锁 image.png|500|500 分布式锁:多进程可见、互斥、高可用、高性能、安全性...... 常见实现方案 ![i...

    2025 年 4 月 23 日 星期三
    3
    阅读全文
  • 「黑马点评」三、优惠券秒杀

    基于 Redis 的全局唯一 ID 生成器 分布式系统下用来生成唯一性 ID 的工具:唯一性、高可用、高性能、递增性、安全性 image.png|500 示例 @Component public class RedisIdWorker { private static final long BEGIN_TIMESTAMP = 1735689600L; private static final int COUNT...

    2025 年 4 月 22 日 星期二
    1
    阅读全文
  • 「黑马点评」二、商户查询缓存

    引入 Redis 作为缓存 引入 Redis 作为 Client 与 Server 之间的缓存存在,查询先经过 Redis 缓存,没有才会访问数据库,然后回写缓存,方便下一次对该数据的查询 image.png|500 示例 对于 queryShop 而言,先查询缓存中有没有,没有再去查询数据库,如果数据库中有就回写到缓存中,并返回 @GetMapping("/{id}") public Result queryShopById(...

    2025 年 4 月 21 日 星期一
    1
    阅读全文
  • 「黑马点评」一、短信登陆及 session 登陆

    基于 session 实现短信登陆 image.png|500 对于短信验证码来说,只有生成、发送、校验三步,在 Service 中即 /sendCode、/login 两步 显然这是利用 B/S 中的 JsessionId 在服务器中存储相关会话信息,即 smsCode 和 user 但是如果多台集群服务下,session 无法共享,所以引出了 Redis 实现短信登陆 ![image.png|500](https://0xling.cy...

    2025 年 4 月 17 日 星期四
    1
    阅读全文
  • 布隆过滤器简述

    一、场景引入 场景 - URL 去重过滤在亿级数据量下的解决方案 以大规模网页爬虫为例,在针对特定关键词的大规模网页爬虫中,待抓取的 URL 数量可能达到数亿,重复 URL 不仅浪费爬取资源,还可能导致爬虫陷入死循环或无效抓取,严重影响抓取效率和数据质量 传统的方案 存入数据库,添加约束 unique I/O 瓶颈 使用缓存,例如 HashSet 内存开销大 方案优化 考虑到 URL 爬虫去重允许误判,大数据量的情况下小部分数据误判完全允许 使用位图,单哈希压缩存储,利用二进制数组记录 URL 是否出现,内存空间占用更小 百...

    2025 年 4 月 10 日 星期四(已编辑)
    14
    阅读全文
  • Mac 配置

    终端安装 iTerm2 直接在网上下载iTerm2 首先 xcode-select --install 配置brew 使用国内源安装 /bin/zsh -c "$(curl -fsSL https://gitee.com/cunkai/HomebrewCN/raw/master/Homebrew.sh)" 配置oh-my-zsh wget https://gitee.com/pocmon/ohmyzsh/raw/master/tools/install.s...

    2024 年 12 月 7 日 星期六(已编辑)
    5
    阅读全文
  • 「笔记007」Go语言Context初识 下

    摘要: 本文介绍了Go语言的context在高级应用场景中的用法,包括多个协程共享context,结合http.Request的上下文管理,以及使用context实现超时重试。 - 在多协程中,父context的取消会影响所有子协程,并用sync.WaitGroup确保协程在主程序退出前完成。 - 在Web开发中,每个请求可用context管理,方便设置超时和传递数据。 - 使用context的Done方法进行任务的重试和超时控制。 注意事项包括避免滥用WithValue,确保资源释放,避免context跨边界传递。 最佳实践强调确定context范围、使用自定义类型作为键、明确取消信号,并避免将context作为函数返回值。

    5. 高级应用场景 5.1 多协程共享 context context 的父子关系可以很好地控制多个协程的生命周期,尤其是在复杂任务中。 示例:任务分发与统一取消 package main import ( "context" "fmt" "sync" "time" ) func worker(ctx context.Context, id int, wg *sync.WaitGroup) { defer wg.Done() for { select {...

    2024 年 11 月 29 日 星期五(已编辑)
    11
    阅读全文
  • 「笔记006」Go语言Context初识 上

    摘要: 在Go语言中,`context`模块主要用于解决协程管理中的难题,如优雅终止协程、复杂的超时控制和跨函数的数据传递问题。通过使用`context`可以传递取消信号、设定任务超时以及传递上下文数据,而不必修改函数签名。重要的函数包括`context.Background`(根context)用于初始化,`context.TODO`(占位context)用于开发阶段,`context.WithCancel`用于手动取消任务,`context.WithTimeout`和`context.WithDeadline`用于自动超时控制,`context.WithValue`用于传递元数据。但传递数据量要少,避免滥用。

    1. 为什么需要 context? 1.1 背景问题 在 Go 中,协程(goroutine)是轻量级线程,可以轻松地启动数以千计的并发任务。然而,这种便利也带来了一些问题: 无法优雅地终止协程: 一旦一个协程启动,除非显式退出,否则它可能一直运行下去,导致资源泄露。 如果一个任务失败了,依赖它的其他任务也需要取消,而传统的手段难以统一管理。 任务的超时控制复杂: 某些操作(如 HTTP 请求、数据库查询)需要超时控制,如果任务超时没有终止,可能会拖垮整个系统。 **函数间依赖数据传递麻...

    2024 年 11 月 29 日 星期五(已编辑)
    10
    阅读全文
  • 「笔记005」Go课程工程实践作业2

    前言 这次实现主要有关作业 1 的三个扩展功能: 用户认证授权 点赞和回复功能 分页和排序功能 一、用户认证授权实现笔记 1. 数据库设计思路 首先扩展用户表,添加认证相关字段: -- 用户表扩展 ALTER TABLE user ADD COLUMN password VARCHAR(255) NOT NULL COMMENT '密码', ADD COLUMN email VARCHAR(100) NOT NULL COMMENT '邮箱', ADD COLUMN last_login DATETIME COMM...

    2024 年 11 月 28 日 星期四(已编辑)
    10
    阅读全文
关于关于本站关于我关于此项目
更多时间线友链监控
联系写留言发邮件GitHub
© 2024-2025 Chanler. | RSS | 站点地图 | | Stay hungry. Stay foolish.
Powered by Mix Space&. | 萌 ICP 备 号 |