diff --git a/docs/distributed-system/distributed-session.md b/docs/distributed-system/distributed-session.md index f39bd9872ae097ca4c2c1fef069962997eb2d2c3..a2b4b976fa0300318d96becccb221c68a1ca36e8 100644 --- a/docs/distributed-system/distributed-session.md +++ b/docs/distributed-system/distributed-session.md @@ -18,7 +18,6 @@ session 是啥？浏览器有个 cookie，在一段时间内这个 cookie 都存 其实方法很多，但是常见常用的是以下几种： ### 完全不用 session - 使用 JWT Token 储存用户身份，然后再从数据库或者 cache 中获取其他的信息。这样无论请求分配到哪个服务器都无所谓。 ### tomcat + redis @@ -53,7 +52,7 @@ session 是啥？浏览器有个 cookie，在一段时间内这个 cookie 都存 因为上面那种 tomcat + redis 的方式好用，但是会**严重依赖于web容器**，不好将代码移植到其他 web 容器上去，尤其是你要是换了技术栈咋整？比如换成了 spring cloud 或者是 spring boot 之类的呢？ -所以现在比较好的还是基于 Java 一站式解决方案，也就是 spring。人家 spring 基本上包掉了大部分我们需要使用的框架，spirng cloud 做微服务，spring boot 做脚手架，所以用 sping session 是一个很好的选择。 +所以现在比较好的还是基于 Java 一站式解决方案，也就是 spring。人家 spring 基本上承包了大部分我们需要使用的框架，spirng cloud 做微服务，spring boot 做脚手架，所以用 sping session 是一个很好的选择。 在 pom.xml 中配置： ```xml diff --git a/docs/distributed-system/dubbo-load-balancing.md b/docs/distributed-system/dubbo-load-balancing.md index 824b2906315ca4d58ae7ecb0b30907aeaf214cf5..3f21fb84cd2f03ac9eccdeac7c3d2fe081b2c02b 100644 --- a/docs/distributed-system/dubbo-load-balancing.md +++ b/docs/distributed-system/dubbo-load-balancing.md @@ -13,14 +13,14 @@ dubbo 负载均衡策略和集群容错策略都有哪些？动态代理策略 ## 面试题剖析 ### dubbo 负载均衡策略 #### random loadbalance -默认情况下，dubbo 是 random load balance **随机**调用实现负载均衡，可以对 provider 不同实例**设置不同的权重**，会按照权重来负载均衡，权重越大分配流量越高，一般就用这个默认的就可以了。 +默认情况下，dubbo 是 random load balance ，即**随机**调用实现负载均衡，可以对 provider 不同实例**设置不同的权重**，会按照权重来负载均衡，权重越大分配流量越高，一般就用这个默认的就可以了。 #### roundrobin loadbalance 这个的话默认就是均匀地将流量打到各个机器上去，但是如果各个机器的性能不一样，容易导致性能差的机器负载过高。所以此时需要调整权重，让性能差的机器承载权重小一些，流量少一些。 举个栗子。 -跟运维同学申请机器，有的时候，我们运气好，正好公司资源比较充足，刚刚有一批热气腾腾、刚刚做好的一批虚拟机新鲜出炉，配置都比较高：8 核 + 16G 机器，申请到 2 台。过了一段时间，我们感觉 2 台机器有点不太够，我就去找运维同学说，“哥儿们，你能不能再给我一台机器”，但是这时只剩下一台 4 核 + 8G 的机器。我要还是得要。 +跟运维同学申请机器，有的时候，我们运气好，正好公司资源比较充足，刚刚有一批热气腾腾、刚刚做好的虚拟机新鲜出炉，配置都比较高：8 核 + 16G 机器，申请到 2 台。过了一段时间，我们感觉 2 台机器有点不太够，我就去找运维同学说，“哥儿们，你能不能再给我一台机器”，但是这时只剩下一台 4 核 + 8G 的机器。我要还是得要。 这个时候，可以给两台 8 核 16G 的机器设置权重 4，给剩余 1 台 4 核 8G 的机器设置权重 2。 diff --git a/docs/distributed-system/dubbo-service-management.md b/docs/distributed-system/dubbo-service-management.md index b1561d588725a8c1144b4befd4b471b3d2b9bae3..9a91c0801a38c978ae8de1f30cd3ab245af1cf5d 100644 --- a/docs/distributed-system/dubbo-service-management.md +++ b/docs/distributed-system/dubbo-service-management.md @@ -48,7 +48,6 @@ public class HelloServiceImpl implements HelloService { System.out.println("hello world......"); } } - ``` ```xml @@ -85,13 +84,13 @@ public class HelloServiceImpl implements HelloService { 我们调用接口失败的时候，可以通过 `mock` 统一返回 null。 mock 的值也可以修改为 true，然后再跟接口同一个路径下实现一个 Mock 类，命名规则是 “接口名称+`Mock`” 后缀。然后在 Mock 类里实现自己的降级逻辑。 + ```java public class HelloServiceMock implements HelloService { public void sayHello() { // 降级逻辑 } } - ``` ### 失败重试和超时重试 diff --git a/docs/high-concurrency/database-shard-dynamic-expand.md b/docs/high-concurrency/database-shard-dynamic-expand.md index 3cc8c8a052631ac46c4215810a49647c6182454d..5fc0d1ac999aee716a011caaf56e6ad170740ea0 100644 --- a/docs/high-concurrency/database-shard-dynamic-expand.md +++ b/docs/high-concurrency/database-shard-dynamic-expand.md @@ -30,13 +30,13 @@ 我可以告诉各位同学，这个分法，第一，基本上国内的互联网肯定都是够用了，第二，无论是并发支撑还是数据量支撑都没问题。 -每个库正常承载的写入并发量是 1000，那么 32 个库就可以承载32 * 1000 = 32000 的写并发，如果每个库承载 1500 的写并发，32 * 1500 = 48000 的写并发，接近 5万/s 的写入并发，前面再加一个MQ，削峰，每秒写入 MQ 8 万条数据，每秒消费 5 万条数据。 +每个库正常承载的写入并发量是 1000，那么 32 个库就可以承载32 * 1000 = 32000 的写并发，如果每个库承载 1500 的写并发，32 * 1500 = 48000 的写并发，接近 5 万每秒的写入并发，前面再加一个MQ，削峰，每秒写入 MQ 8 万条数据，每秒消费 5 万条数据。 有些除非是国内排名非常靠前的这些公司，他们的最核心的系统的数据库，可能会出现几百台数据库的这么一个规模，128个库，256个库，512个库。 1024 张表，假设每个表放 500 万数据，在 MySQL 里可以放 50 亿条数据。 -每秒的 5 万写并发，总共 50 亿条数据，对于国内大部分的互联网公司来说，其实一般来说都够了。 +每秒 5 万的写并发，总共 50 亿条数据，对于国内大部分的互联网公司来说，其实一般来说都够了。 谈分库分表的扩容，**第一次分库分表，就一次性给他分个够**，32 个库，1024 张表，可能对大部分的中小型互联网公司来说，已经可以支撑好几年了。