From 2b3e07e8daf395de9b34efa43278d805da81f0d9 Mon Sep 17 00:00:00 2001 From: sid <673088860@qq.com> Date: Sun, 29 Dec 2019 11:08:51 +0800 Subject: [PATCH 1/3] =?UTF-8?q?=E4=BF=AE=E6=94=B9=E9=94=99=E5=88=AB?= =?UTF-8?q?=E5=AD=97?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/database/Redis/Redis.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/database/Redis/Redis.md b/docs/database/Redis/Redis.md index 02f4de14..c5dbfda3 100644 --- a/docs/database/Redis/Redis.md +++ b/docs/database/Redis/Redis.md @@ -293,7 +293,7 @@ Redis 通过 MULTI、EXEC、WATCH 等命令来实现事务(transaction)功能。 最基本的就是首先做好参数校验，一些不合法的参数请求直接抛出异常信息返回给客户端。比如查询的数据库 id 不能小于 0、传入的邮箱格式不对的时候直接返回错误消息给客户端等等。 -**1）缓存无效 key** : 如果缓存和数据库都查不到某个 key 的数据就写一个到 redis 中去并设置过期时间，具体命令如下：`SET key value EX 10086`。这种方式可以解决请求的 key 变化不频繁的情况，如何黑客恶意攻击，每次构建的不同的请求key，会导致 redis 中缓存大量无效的 key 。很明显，这种方案并不能从根本上解决此问题。如果非要用这种方式来解决穿透问题的话，尽量将无效的 key 的过期时间设置短一点比如 1 分钟。 +**1）缓存无效 key** : 如果缓存和数据库都查不到某个 key 的数据就写一个到 redis 中去并设置过期时间，具体命令如下：`SET key value EX 10086`。这种方式可以解决请求的 key 变化不频繁的情况，如果黑客恶意攻击，每次构建的不同的请求key，会导致 redis 中缓存大量无效的 key 。很明显，这种方案并不能从根本上解决此问题。如果非要用这种方式来解决穿透问题的话，尽量将无效的 key 的过期时间设置短一点比如 1 分钟。 另外，这里多说一嘴，一般情况下我们是这样设计 key 的： `表名:列名:主键名:主键值`。 From 2c36a40a89f14522d23cae5a545dab6d6b313201 Mon Sep 17 00:00:00 2001 From: sid <673088860@qq.com> Date: Sun, 29 Dec 2019 11:10:39 +0800 Subject: [PATCH 2/3] =?UTF-8?q?=E4=BF=AE=E6=94=B9=E9=94=99=E5=88=AB?= =?UTF-8?q?=E5=AD=97?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/database/Redis/Redis.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/database/Redis/Redis.md b/docs/database/Redis/Redis.md index c5dbfda3..0ede4e8f 100644 --- a/docs/database/Redis/Redis.md +++ b/docs/database/Redis/Redis.md @@ -293,7 +293,7 @@ Redis 通过 MULTI、EXEC、WATCH 等命令来实现事务(transaction)功能。 最基本的就是首先做好参数校验，一些不合法的参数请求直接抛出异常信息返回给客户端。比如查询的数据库 id 不能小于 0、传入的邮箱格式不对的时候直接返回错误消息给客户端等等。 -**1）缓存无效 key** : 如果缓存和数据库都查不到某个 key 的数据就写一个到 redis 中去并设置过期时间，具体命令如下：`SET key value EX 10086`。这种方式可以解决请求的 key 变化不频繁的情况，如果黑客恶意攻击，每次构建的不同的请求key，会导致 redis 中缓存大量无效的 key 。很明显，这种方案并不能从根本上解决此问题。如果非要用这种方式来解决穿透问题的话，尽量将无效的 key 的过期时间设置短一点比如 1 分钟。 +**1）缓存无效 key** : 如果缓存和数据库都查不到某个 key 的数据就写一个到 redis 中去并设置过期时间，具体命令如下：`SET key value EX 10086`。这种方式可以解决请求的 key 变化不频繁的情况，如果黑客恶意攻击，每次构建不同的请求key，会导致 redis 中缓存大量无效的 key 。很明显，这种方案并不能从根本上解决此问题。如果非要用这种方式来解决穿透问题的话，尽量将无效的 key 的过期时间设置短一点比如 1 分钟。 另外，这里多说一嘴，一般情况下我们是这样设计 key 的： `表名:列名:主键名:主键值`。 From 4666687ff375927c80d0a95f60fe1e8deebad5a0 Mon Sep 17 00:00:00 2001 From: sid <673088860@qq.com> Date: Sun, 5 Jan 2020 15:59:21 +0800 Subject: [PATCH 3/3] =?UTF-8?q?Dueue=E5=BA=94=E8=AF=A5=E6=94=B9=E6=88=90De?= =?UTF-8?q?que=EF=BC=8C=E5=8F=8C=E7=AB=AF=E9=98=9F=E5=88=97=E7=9A=84?= =?UTF-8?q?=E6=84=8F=E6=80=9D?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../Kafka系统设计开篇-面试看这篇就够了.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/system-design/data-communication/Kafka系统设计开篇-面试看这篇就够了.md b/docs/system-design/data-communication/Kafka系统设计开篇-面试看这篇就够了.md index e617c3b3..d21fad3a 100644 --- a/docs/system-design/data-communication/Kafka系统设计开篇-面试看这篇就够了.md +++ b/docs/system-design/data-communication/Kafka系统设计开篇-面试看这篇就够了.md @@ -50,7 +50,7 @@ Consumer Group：同一个Consumer Group中的Consumers，Kafka将相应Topic中 ProducerRecord对象中如果指定了partition，就使用这个partition。否则根据key和topic的partition数目取余，如果key也没有的话就随机生成一个counter，使用这个counter来和partition数目取余。这个counter每次使用的时候递增。 **2发送到batch&&唤醒Sender 线程** -根据topic-partition获取对应的batchs（Dueue），然后将消息append到batch中.如果有batch满了则唤醒Sender 线程。队列的操作是加锁执行，所以batch内消息时有序的。后续的Sender操作当前方法异步操作。 +根据topic-partition获取对应的batchs（Deque），然后将消息append到batch中.如果有batch满了则唤醒Sender 线程。队列的操作是加锁执行，所以batch内消息时有序的。后续的Sender操作当前方法异步操作。 ![send_msg](https://blog-article-resource.oss-cn-beijing.aliyuncs.com/kafka/send2Batch1.png)![send_msg2](https://blog-article-resource.oss-cn-beijing.aliyuncs.com/kafka/send2Batch2.png)