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. 这才是真正的分布式锁
微服务：重复，幂等性，并发
什么时候用缓存：读多写少