File tree Expand file tree Collapse file tree 4 files changed +22
-7
lines changed Expand file tree Collapse file tree 4 files changed +22
-7
lines changed Original file line number Diff line number Diff line change @@ -768,7 +768,7 @@ public class ConsumerAddViewHistory implements RocketMQListener<Message> {
768768
769769### 传统 IO 方式
770770
771- ![ 3 ] ( https://img1.imgtp.com/2023/08/15/9DQUZuL7.png )
771+ ![ ] ( https://oss.javaguide.cn/github/javaguide/high-performance/message-queue/31699457085_.pic.jpg )
772772
773773传统的 IO 读写其实就是 read + write 的操作,整个过程会分为如下几步
774774
@@ -791,7 +791,7 @@ mmap(memory map)是一种内存映射文件的方法,即将一个文件或
791791
792792简单地说就是内核缓冲区和应用缓冲区共享,从而减少了从读缓冲区到用户缓冲区的一次 CPU 拷贝。基于此上述架构图可变为:
793793
794- ![ 4 ] ( https://img1.imgtp.com/2023/08/15/CHmGd0II.png )
794+ ![ ] ( https://oss.javaguide.cn/github/javaguide/high-performance/message-queue/41699457086_.pic.jpg )
795795
796796基于 mmap IO 读写其实就变成 mmap + write 的操作,也就是用 mmap 替代传统 IO 中的 read 操作。
797797
@@ -808,7 +808,7 @@ MappedByteBuffer mappedByteBuffer = fileChannel.map(FileChannel.MapMode.READ_WRI
808808
809809sendfile()跟 mmap()一样,也会减少一次 CPU 拷贝,但是它同时也会减少两次上下文切换。
810810
811- ![ 5 ] ( https://img1.imgtp.com/2023/08/15/jqLgCEBY.png )
811+ ![ ] ( https://oss.javaguide.cn/github/javaguide/high-performance/message-queue/51699457087_.pic.jpg )
812812
813813如图,用户在发起 sendfile()调用时会发生切换 1,之后数据通过 DMA 拷贝到内核缓冲区,之后再将内核缓冲区的数据 CPU 拷贝到 Socket 缓冲区,最后拷贝到网卡,sendfile()返回,发生切换 2。发生了 3 次拷贝和两次切换。Java 也提供了相应 api:
814814
Original file line number Diff line number Diff line change @@ -244,7 +244,7 @@ ShardingSphere 的优势如下(摘自 ShardingSphere 官方文档:<https://s
244244
245245另外,ShardingSphere 的生态体系完善,社区活跃,文档完善,更新和发布比较频繁。
246246
247- 艿艿之前写了一篇分库分表的实战文章,各位朋友可以看看: [ 《芋道 Spring Boot 分库分表入门》 ] ( https://mp.weixin.qq.com/s/A2MYOFT7SP-7kGOon8qJaw ) 。
247+ 不过,还是要多提一句: ** 现在很多公司都是用的类似于 TiDB 这种分布式关系型数据库,不需要我们手动进行分库分表(数据库层面已经帮我们做了),也不需要解决手动分库分表引入的各种问题,直接一步到位,内置很多实用的功能(如无感扩容和缩容、冷热存储分离)!如果公司条件允许的话,个人也是比较推荐这种方式! **
248248
249249### 分库分表后,数据怎么迁移呢?
250250
@@ -266,6 +266,7 @@ ShardingSphere 的优势如下(摘自 ShardingSphere 官方文档:<https://s
266266- 读写分离基于主从复制,MySQL 主从复制是依赖于 binlog 。
267267- ** 分库** 就是将数据库中的数据分散到不同的数据库上。** 分表** 就是对单表的数据进行拆分,可以是垂直拆分,也可以是水平拆分。
268268- 引入分库分表之后,需要系统解决事务、分布式 id、无法 join 操作问题。
269- - ShardingSphere 绝对可以说是当前分库分表的首选!ShardingSphere 的功能完善,除了支持读写分离和分库分表,还提供分布式事务、数据库治理等功能。另外,ShardingSphere 的生态体系完善,社区活跃,文档完善,更新和发布比较频繁。
269+ - 现在很多公司都是用的类似于 TiDB 这种分布式关系型数据库,不需要我们手动进行分库分表(数据库层面已经帮我们做了),也不需要解决手动分库分表引入的各种问题,直接一步到位,内置很多实用的功能(如无感扩容和缩容、冷热存储分离)!如果公司条件允许的话,个人也是比较推荐这种方式!
270+ - 如果必须要手动分库分表的话,ShardingSphere 是首选!ShardingSphere 的功能完善,除了支持读写分离和分库分表,还提供分布式事务、数据库治理等功能。另外,ShardingSphere 的生态体系完善,社区活跃,文档完善,更新和发布比较频繁。
270271
271272<!-- @include: @article-footer.snippet.md -->
Original file line number Diff line number Diff line change @@ -267,7 +267,7 @@ public E take() throws InterruptedException {
267267 }
268268 }
269269 } finally {
270- // 收尾逻辑:如果leader不为空且q有元素,则说明有任务没人认领,直接发起通知唤醒因为锁被当前消费者持有而导致阻塞的生产者(即调用put、add、offer的线程)
270+ // 收尾逻辑:当leader为null,并且队列中有任务时,唤醒等待的获取元素的线程。
271271 if (leader == null && q. peek() != null )
272272 available. signal();
273273 // 释放锁
Original file line number Diff line number Diff line change @@ -75,6 +75,7 @@ icon: "xitongsheji"
7575## 搜索引擎
7676
7777- [ Elasticsearch] ( https://github.com/elastic/elasticsearch " elasticsearch ") (推荐):开源,分布式,RESTful 搜索引擎。
78+ - [ Meilisearch] ( https://github.com/meilisearch/meilisearch ) :一个功能强大、快速、开源、易于使用和部署的搜索引擎,支持中文搜索(不需要添加额外的配置)。
7879- [ Solr] ( https://lucene.apache.org/solr/ ) : Solr(读作“solar”)是 Apache Lucene 项目的开源企业搜索平台。
7980- [ Easy-ES] ( https://gitee.com/dromara/easy-es ) :傻瓜级 ElasticSearch 搜索引擎 ORM 框架。
8081
@@ -148,10 +149,23 @@ icon: "xitongsheji"
148149
149150### 缓存
150151
152+ #### 本地缓存
153+
151154- [ Caffeine] ( https://github.com/ben-manes/caffeine ) : 一款强大的本地缓存解决方案,性能非常强大。
152- - [ Redis ] ( https://github.com/redis/redis ) :一个使用 C 语言开发的内存数据库,分布式缓存首选 。
155+ - [ Guava ] ( https://github.com/google/guava ) :Google Java 核心库,内置了比较完善的本地缓存实现 。
153156- [ OHC] ( https://github.com/snazy/ohc ) :Java 堆外缓存解决方案(项目从 2021 年开始就不再进行维护了)。
154157
158+ #### 分布式缓存
159+
160+ - [ Redis] ( https://github.com/redis/redis ) :一个使用 C 语言开发的内存数据库,分布式缓存首选。
161+ - [ Dragonfly] ( https://github.com/dragonflydb/dragonfly ) :一种针对现代应用程序负荷需求而构建的内存数据库,完全兼容Redis和Memcached的 API,迁移时无需修改任何代码,号称全世界最快的内存数据库。
162+ - [ KeyDB] ( https://github.com/Snapchat/KeyDB ) : Redis 的一个高性能分支,专注于多线程、内存效率和高吞吐量。
163+
164+ #### 多级缓存
165+
166+ - [ J2Cache] ( https://gitee.com/ld/J2Cache ) :基于本地内存和 Redis 的两级 Java 缓存框架。
167+ - [ JetCache] ( https://github.com/alibaba/jetcache ) :阿里开源的缓存框架,支持多级缓存、分布式缓存自动刷新、 TTL 等功能。
168+
155169### 消息队列
156170
157171** 分布式队列** :
You can’t perform that action at this time.
0 commit comments