2021-02-10

9 分钟读完 (大约 1276 个字)

读书_w3c架构师02典型架构实践

读书_w3c架构师02通用设计与方法论

配置”也有架构演进？看完深有痛感

什么痛点？
上游痛：扩容的是下游，改配置重启的是上游
下游痛：不知道谁依赖于自己

配置架构如何演进？
一、配置私藏
二、全局配置文件
三、配置中心

架构设计中，dns有它独特的功能和作用：
dns轮询，水平扩展反向代理层
去掉反向代理层，利用dns实施负载均衡
智能dns，根据用户ip来就近访问服务器

保证session一致性的架构设计常见方法：

session同步法：多台web-server相互同步数据  
客户端存储法：一个用户只存储自己的数据  
反向代理hash一致性：四层hash和七层hash都可以做，保证一个用户的请求落在一台web-server上  
后端统一存储：web-server重启和扩容，session也不会丢失

对于方案3和方案4，个人建议推荐后者：

1
2

web层、service层无状态是大规模分布式系统设计原则之一，session属于状态，不宜放在web层  
让专业的软件做专业的事情，web-server存session？还是让cache去做这样的事情吧

这个方案叫做“count”计数法，在数据量并发量不大的情况下，最容易想到且最经常使用的就是这种方法，但随着数据量的上升，并发量的上升，这个方法的弊端将逐步展现。
“count”计数法方案，可以总结为：

1
2
3

多条消息多次查询，for循环进行  
一条消息多次查询，多个计数的查询  
一次查询一个count，每个计数都是一个count语句

这个方案称为“计数外置”，可以总结为：

1
2
3

通过counting-service单独保存计数  
MQ同步计数的变更  
多条消息的多个计数，一个批量IN查询完成

计数外置，本质是数据的冗余，架构设计上，数据冗余必将引发数据的一致性问题，需要有机制来保证计数系统里的数据与业务系统里的数据一致，常见的方法有：

1
2

对于一致性要求比较高的业务，要有定期check并fix的机制，例如关注计数，粉丝计数，微博消息计数等  
对于一致性要求比较低的业务，即使有数据不一致，业务可以接受，例如微博浏览数，微博转发数等

小小的计数，在数据量大，并发量大的时候，其架构实践思路为：

1
2
3

计数外置：由“count计数法”升级为“计数外置法”  
读多写少，甚至写多但一致性要求不高的计数，需要进行缓存优化，降低数据库压力  
缓存kv设计优化，可以由[key:type]->[count]，优化为[key]->[c1:c2:c3]

即：

优化为：

数据库扩展性优化，可以由列扩展优化为行扩展

优化为：