update note

Tyson0314 · Tyson0314 · commit cab4766cff10 · 2020-08-19T09:22:56.000+08:00
diff --git a/中间件/RabbitMQ.md b/中间件/RabbitMQ.md
@@ -250,7 +250,7 @@ spring.rabbitmq.listener.simple.acknowledge-mode=manual
 
 当 RabbitMQ 服务器积压大量消息时，队列里的消息会大量涌入消费端，可能导致消费端服务器奔溃。这种情况下需要对消费端限流。
 
-Spring RabbitMQ 提供参数 prefetch 可以设置消费者同时处理的最大消息个数。如果消费者同时处理的消息到达最大值的时候，则该消费者会阻塞，不会消费新的消息，直到有消息 ack 才会消费新的消息。
+Spring RabbitMQ 提供参数 prefetch 可以设置单个请求处理的消息个数。如果消费者同时处理的消息到达最大值的时候，则该消费者会阻塞，不会消费新的消息，直到有消息 ack 才会消费新的消息。
 
 开启消费端限流：
 
diff --git a/数据库/mysql进阶.md b/数据库/mysql进阶.md
@@ -454,6 +454,8 @@ Java JUC中的atomic包就是乐观锁的一种实现，AtomicInteger 通过CAS
 
 ## 分库分表
 
+[分库分表](https://blog.csdn.net/weixin_44062339/article/details/100491744)
+
 垂直划分数据库是根据业务进行划分，例如将shop库中涉及商品、订单、用户的表分别划分出成一个库，通过降低单库的大小来提高性能，但这种方式并没有解决高数据量带来的性能损耗。同样的，分表的情况就是将一个大表根据业务功能拆分成一个个子表，例如用户表可根据业务分成基本信息表和详细信息表等。
 优点：拆分后业务清晰，达到专库专用；便于维护
 缺点：不解决数据量大带来的性能损耗，读写压力依旧很大；不同的业务无法跨库关联（join），只能通过业务来关联
@@ -581,7 +583,7 @@ SELECT ... FOR UPDATE
 
 这两种方式主要的不同在于LOCK IN SHARE MODE 多个事务同时更新同一个表单时很容易造成死锁。这种情况最好使用SELECT ...FOR UPDATE。
 
-`select * from goods where id = 1 for update`：申请排他锁的前提是，没有线程对该结果集的任何行数据使用排它锁或者共享锁，否则申请会受到阻塞。for update 仅适用于Innodb，且必须在事务范围内才能生效。在进行事务操作时，mysql会对查询结果集的每行数据添加排它锁，其他线程对这些数据的更改或删除操作会被阻塞，直到该语句的事务被commit语句或rollback语句结束为止。
+`select * from goods where id = 1 for update`：申请排他锁的前提是，没有线程对该结果集的任何行数据使用排它锁或者共享锁，否则申请会受到阻塞。for update 仅适用于Innodb，且必须在事务范围内才能生效。在进行事务操作时，mysql会对查询结果集的每行数据添加排它锁，其他线程对这些数据的更改或删除操作会被阻塞（只能读操作），直到该语句的事务被commit语句或rollback语句结束为止。
 
 
 
