soyo的跨机房部署、同城双活、异地多活、9个9高可用博客yuque笔记同步site

ε=(´ο｀*)))唉，学Java的这辈子有了

发表于 更新于 分类于

具体可以参考其他优秀组件

aerospike

近几年来分布式缓存的组件层出不穷，但真要论一出来就轰动，性能秒杀Redis的也只有Dragonfly

Dragonfly：

:::color4
是一种针对现代应用程序负荷需求而构建的内存数据库，完全兼容Redis和Memcached的 API，迁移时无需修改任何代码。相比于这些传统的内存数据库，Dragonfly提供了其25倍的吞吐量，高缓存命中率和低尾延迟，并且对于相同大小的工作负载运行资源最多可减少80%。

:::

dragonfly/README.zh-CN.md at main · dragonflydb/dragonfly

核心理念就是丢掉历史包袱，思考在2022我们会怎么去设计一款缓存数据库

base

1.无共享式架构，也就是每个线程都有自己的内存

2.重新设计hash表，一种高效的hash表：dash table

https://github.com/dragonflydb/dragonfly/blob/main/docs/dashtable.md

3.多键并发操作的原子性保证

feature：

- <font style="color:rgb(31, 35, 40);">针对TTL的高效记录过期功能。</font>
- <font style="color:rgb(31, 35, 40);">一种新颖的缓存驱逐算法，具有比其他缓存策略（如LRU和LFU）更高的命中率，同时</font>**<font style="color:rgb(31, 35, 40);">零内存开销</font>**<font style="color:rgb(31, 35, 40);">。</font>
- <font style="color:rgb(31, 35, 40);">一种新颖的无fork快照算法。</font>

发表于 分类于

同步辅助类，它允许一个或多个线程等待其他线程完成操作后再继续执行

- **核心理念：****计数器 + 阻塞**
- **构造器：**

CountDownLatch latch = new CountDownLatch(int count);

count = 需要等待的事件数（或线程数）

使用：latch.await() 这时候线程就会park,并进入q，state++。countdown()：try state == 0，里面有个 dorelease，就会for node: q, node即Thread，然后LockSuport.unpark()

底层原理：

还是基于AQS，可见AQS的抽象能力和通用性，

核心就是 计数器归零唤醒所有等待线程

常用场景

常用于我们的一些需要聚合数据的业务场景中，比如前端的一个页面需要多个组件的数据进行聚合，那么这时候就可以使用countDownLatch开多个线程

还有模拟高并发场景，同时唤醒多个请求任务，唤醒这个操作是比较轻量级的，虽然底层是for(T

thread：q)但几乎能做到同时

发表于 分类于

juc下的smphone计数信号量，用于控制同时访问某资源的线程数量，也就是限流

可用来实现限流

用法：

Semaphore sp = new Semaphore(//可同时访问某资源的线程数量)

sp.acquire() 就会 permits ++

sp.acquire() 就会 permits ++

底层其实就是基于AQS实现的，跟ReentrantLock某种方面实现基本一致，只是计数器的实现不太一样

发表于 分类于

首先要明白一个技术点他是为了什么而诞生的，是用来干什么，怎么用

搞清楚以上三点，OK，开始理解它的实现原理，然后意淫它的业务场景，然后把它往下扩展和延伸到哪

然后背的时候，多反问xx的本质到底是什么，到底是个啥

发表于

可能会说什么发不丢，存不丢，收不丢，这其实是片面的

真实场景没人会完全依靠中间件的机制来保证不丢，一般我们都是基于自己记了再发，即记日志然后再发消息

所以说记日志是一件很重要的事情

保证分布式一致性，其实说来说去就是 本地持久化，确认机制和重试机制

容错、分片

发表于 分类于

好的，我给你一个简洁版英文优化建议 Issue 模板，但每一行我会加中文注释，方便你理解和复用。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
markdown


复制编辑
## Optimization Suggestion  <!-- 优化建议标题 -->

**Background**  <!-- 背景：简述遇到的问题或不便之处 -->
<!-- e.g., Current API response time is slow when handling large datasets. -->

**Proposed Improvement**  <!-- 提议的优化方案：用简短的句子说明你的改进想法 -->
<!-- e.g., Use batch processing instead of handling items one by one. -->

**Impact**  <!-- 影响范围：性能提升、可维护性、用户体验等 -->
<!-- e.g., Improves performance and reduces server CPU usage. -->

**Additional Context (Optional)**  <!-- 额外信息（可选）：性能数据、参考链接、相关代码等 -->
<!-- e.g., Related issue: #123, Benchmark shows ~20% improvement. -->

这个模板特点：

  • 短：四个核心字段，维护者能在 10 秒内看懂。
  • 适合优化类 PR：没有多余字段，直接背景→方案→影响。
  • 方便复制：可以直接粘到 GitHub Issue 描述里用。