复习
2018.12.24:
1. 秒杀系统架构优化思路
2. 细聊分布式ID生成方法
a. 传统签名算法与文本完整性判断: md5是一种签名算法,常用来判断数据的完整性与一致性
b. 文本相似性的签名算法: 局部敏感哈希LSH(Locality Sensitive Hash)
问题的提出:什么是minHash?
回答:minHash是局部敏感哈希的一种,它常用来快速判定集合的相似性,也常用于检测网页的重复性,其思路为,用相同的规则抽取集合中的少部分元素代表整个集合,如果少部分元素的重合度很高,非常可能整个集合的重复度也很高。
c. minHash与长文本重复度检测有什么关系:目前看来没什么关系,但如果我们能将每一个长文本用一个集合来表示,就能将长文本的相似度用minHash来解决了。
问题的提出:如何将长文本转化为集合? 回答:我去,分词不是就可以么
d. 还有没有更有效的方法: 使用上述方法进行文本相似度检测,需要进行中文分词,词频统计,哈希值计算,相似度计算,计算量微大。然而,抄袭成风,一字不改的风气,让技术有了更广阔的优化空间,赞!
怎么优化呢?不再进行分词,而是进行“分句”,用标点符号把长文按照句子分开,使用N个句子集合(例如一篇文章中5条最长的句子作为签名,注意,长句子比短句子更具有区分性)作为文章的签名,在抄袭成风的互联网环境下,此法判断网页的重复度能大大降低工程复杂度,并且准确度也异常的高。
5. 线程数究竟设多少合理
N核服务器,通过执行业务的单线程分析出本地计算时间为x,等待时间为y,则工作线程数(线程池线程数)设置为 N*(x+y)/x,能让CPU的利用率最大化。
机器能抗住么?如果扛不住,需要加多少台机器?数据库需要分库么?如果需要分库,需要分几个库?
a.评估总访问量 -> 询问业务、产品、运营
b.评估平均访问量QPS -> 除以时间,一天算4w秒
c.评估高峰QPS -> 根据业务曲线图来
d.评估系统、单机极限QPS -> 压测很重要
e.根据线上冗余度回答两个问题 -> 估计冗余度与线上冗余度差值
a. 单点系统存在的问题:可用性问题,性能瓶颈问题
b. shadow-master是一种常见的解决单点系统可用性问题的方案
c. 减少与单点的交互,是存在单点的系统优化的核心方向,常见方法有批量写,客户端缓存
d. 水平扩展也是提升单点系统性能的好方案
8. 一分钟了解负载均衡的一切
常见互联网分布式架构如上,分为客户端层、反向代理nginx层、站点层、服务层、数据层。可以看到,每一个下游都有多个上游调用,只需要做到,每一个上游都均匀访问每一个下游,就能实现“将请求/数据【均匀】分摊到多个操作单元上执行”。
负载均衡(Load Balance)是分布式系统架构设计中必须考虑的因素之一,它通常是指,将请求/数据【均匀】分摊到多个操作单元上执行,负载均衡的关键在于【均匀】。
a.客户端层 到 反向代理层 的负载均衡,是通过“DNS轮询”实现的
b.反向代理层 到 站点层 的负载均衡,是通过“nginx”实现的
c.站点层 到 服务层 的负载均衡,是通过“服务连接池”实现的
d.的负载均衡,要考虑“数据的均衡”与“请求的均衡”两个点,常见的方式有“按照范围水平切分”与“hash水平切分”
2018.12.25
1).接入层架构要考虑的问题域为:高可用、扩展性、反向代理+扩展均衡
2).nginx、keepalived、lvs、f5可以很好的解决高可用、扩展性、反向代理+扩展均衡的问题
3).水平扩展scale out是解决扩展性问题的根本方案,DNS轮询是不能完全被nginx/lvs/f5所替代的
提高系统并发能力的方式,方法论上主要有两种:垂直扩展(Scale Up)与水平扩展(Scale Out)
保证系统高可用,架构设计的核心准则是:冗余。
有了冗余之后,还不够,每次出现故障需要人工介入恢复势必会增加系统的不可服务实践。所以,又往往是通过“自动故障转移”来实现系统的高可用。
20181226
1. 数据库软件架构设计些什么: 数据库架构设计思路:可用性(58用双主当主从用?);读性能(缓存,读写库);一致性(双缓存);扩展性(1->2->4->8)
2. 缓存架构设计细节二三事
3. 细聊冗余表数据一致性:【如果出现不一致】,谁先做对业务的影响较小,就谁先执行
4. 缓存与数据库一致性保证
5. 主从DB与cache一致性:
在“异常时序”或者“读从库”导致脏数据入缓存时,可以用二次异步淘汰的“缓存双淘汰”法来解决缓存与数据库中数据不一致的问题,具体实施至少有三种方案:
1).timer异步淘汰(本文没有细讲,本质就是起个线程专门异步二次淘汰缓存)
2).总线异步淘汰
3).读binlog异步淘汰
10. 就这样把根目录删了!!!
11. 如何防止根目录被删?
12. 即使删了全库,保证半小时恢复
13. 啥,又要为表增加一列属性?
14. 这才是真正的表扩展方案
15. 100亿数据1万属性数据架构设计
16. 一分钟掌握数据库垂直拆分:当应用方需要同时访问主表和扩展表中的属性时,服务层不要使用join来连表访问,而应该分两次进行查询
原因是,大数据高并发互联网场景下,一般来说,吞吐量和扩展性是主要矛盾:
(1)join更消损耗数据库性能
(2)join会让base表和ext表耦合在一起(必须在一个数据库实例上),不利于数据量大时拆分到不同的数据库实例上(机器上)。毕竟减少数据量,提升性能才是垂直拆分的初衷。
(3) 锁表时间更长
17. 数据库秒级平滑扩容架构方案
19. 微信为什么不丢消息?
20. 微信为啥不丢“离线消息”?
21. QQ状态同步究竟是推还是拉?
24. 58到家通用实时消息平台架构细节
25. 微信为啥这么省流量?
2018.12.27
10. 如何实现超高并发的无锁缓存?
11. “id串行化”到底是怎么实现的?
2018.12.28
6. 这才是真正的分布式锁
微服务:重复,幂等性,并发
什么时候用缓存:读多写少