Jet_qi的博客

包含如何学习架构?推模式：推模式就是，用户A关注了用户 B，用户 B 每发送一个动态，后台遍历用户B的粉丝，往他们粉丝的 feed 里面推送一条动态。拉模式：推模式相反，拉模式则是，用户每次刷新 feed 第一页，都去遍历关注的人，把最新的动态拉取回来。一般采用推拉结合的方式，用户发送状态之后，先推送给粉丝里面在线的用户，然后不在线的那部分等到上线的时候再来拉取。另外冷热数据分离，用户关系在缓存里面可以设置一个过期时间，比如七天。七天没上线的可能就很少用这个 APP。可以类比b站推送实时弹幕。

本文是架构设计第七讲，数据巡检系统之daily&线上表结构自动化比对，避免正式环境与测试环境数据库/表、列结构不一致带来问题。

本文是架构设计第8讲：架构 - 理解架构的模式2。设计模式是前人通过大量的实践总结出来的一些经验总结和最佳实践。在经过多年的软件开发实践之后，回过头来去看23种设计模式你会发现很多平时写代码的套路和OO的套路和设计模式里总结的类似，这也说明了你悟到的东西和别人悟到的一样，经过大量实践总能趋向性得出一些最佳实践的结论。架构设计也是一样，这里结合自己的理解分析一下微软给出的云架构的一些模式

本文是架构设计第五讲：数据巡检系统的设计与应用。保障系统上下游数据一致性

各表数据量统计目前单表数据量几千条，数据量并不大daily环境数据量为线上环境2~4倍线上：rm-wz936ji5413x9l86j 2核, 4096MB内存, 20GB磁盘daily：rm-wz9d545c689v19pss 1核, 1024MB内存, 20GB磁盘。

随着互联网的普及，内容信息越来越复杂，用户数和访问量越来越大，我们的应用需要支撑更多的并发量，同时我们的应用服务器和数据库服务器所做的计算也越来越多。但是往往我们的应用服务器资源是有限的，且技术变革是缓慢的，数据库每秒能接受的请求次数也是有限的（或者文件的读写也是有限的），如何能够有效利用有限的资源来提供尽可能大的吞吐量?一个有效的办法就是引入缓存，打破标准流程，每个环节中请求可以从缓存中直接获取目标数据并返回，从而减少计算量，有效提升响应速度，让有限的资源服务更多的用户。

每个系统都有服务的上线，所以当流量超过服务极限能力时，系统可能会出现卡死、崩溃的情况，所以就有了降级和限流。限流其实就是：当高并发或者瞬时高并发时，为了保证系统的稳定性、可用性，系统以牺牲部分请求为代价或者延迟处理请求为代价，保证系统整体服务可用。

传统的ELK方案是一种滞后的业务追踪，需要事后从大量离散的日志中搜集和筛选出需要的日志，并人工进行日志的串联分析，其过程必然耗时耗力。而分布式会话跟踪方案则是在调用执行的同时，实时地完成了链路的动态串联，但由于是会话级别且仅关注于调用关系等问题，导致其无法很好地应用于业务追踪。因此，无论是传统的ELK方案还是分布式会话跟踪方案，都难以满足日益复杂的业务追踪需求。