不合理的需求，如何能轻松搞定？文章较长，建议提前收藏。可能99%的同学不做搜索引擎，但99%的同学一定实现过检索功能。搜索，检索，这里面到底包含哪些技术，希望本文能够给大家一些启示。需求一：我想做一个全网搜索引擎，不复杂，和百度类似就行，两个月能上线吗？

*/*文本协议的特点是：（1）可读性好，便于调试；（2）扩展性较好，能通过key:value扩展；（3）解析效率不高，一行一行读入，按照冒号分割，解析key和value；（4）对二进制不友好

微服务分层架构，之前聊得很多了，微服务离不开RPC框架，RPC框架的原理、实践及细节，今天和大家聊一聊。文章较长，1万字左右，建议提前收藏。服务化有什么好处？服务化的一个好处就是，不限定服务的提供方使用什么技术选型，能够实现大公司跨团队的技术解耦，如下图所示：（1）服务A：欧洲团队维护，技术背景是Java；（2）服务B：美洲团队维护，用C++实现；（3）服务C：中国团队维护，技术栈是go；服务的上游调用方，按照接口、协议即可完成对远端服务的调用。但实际上，大部分互联网公司，研发团队规模有限，大都使用同一套技术体系来实现服务：这样的话，如果没有统一的服务框架，各个团队的服务提供方就需要各自实现一套序列化、反序列化、网络框架、连接池、收发线程、超时处理、状态机等“业务之外”的重复技术劳动，造成整体的低效。因此，统一服务框架把上述“业务之外”的工作统一实现，是服务化首要解决的问题。什么是RPC？Remote

懒淘汰的核心是：（1）item不会被主动淘汰，即没有超时线程，也没有信号通知来主动检查；（2）item每次会查询(get)时，检查一下时间戳，如果已经过期，被动淘汰，并返回cache

《MySQL自增ID，居然大部分人都搞错了？》中的作业题，有少量答对的人，但原理讲得不透，今天简单说下作业题中的答案，以及相关知识点。作业题是这样的：drop

Java》译本出炉了，受邀为译本写推荐序，荣幸至极。新书上架，第一时间推荐给大家，也送一批给大家，希望大家有收获。编程语言和编程思想这两个部分，对我影响最为深远的，无疑是Bruce

《MySQL删除数据的三种方式》中的作业题，99%的人答错，有点出乎意料。画外音：评论中不乏嘲笑知识点简单的小伙伴。今天简单说下作业题中的答案，以及知识点。作业题是这样的：实验步骤如上图：第一步：建表，设定自增列；第二步：指定id=1插入，锚定第一行是id是1；第三步：不指定id，依赖自增机制，插入3行；画外音：此时id应该变为2，3，4了？第四步：delete删除所有记录；画外音：坑就容易出在这里。第五步：指定id=0插入；第六步：指定id=1插入；第七步：不指定id，依赖自增机制，插入1行；请问，此时表中的三行记录，id分别是多少？知识点一：delete数据后，自增列计数不会从头开始。画外音：truncate数据后，自增列计数会从头开始。因此，在第四步delete删除所有4条记录后，自增列计数，并不会重新归0，也就是说，下一条insert的记录，自增列的值会是5。知识点二：含自增列的表，插入时可以手动指定自增列的值，但不能与已有值冲突，也可以使用系统默认自增列的值。因此，第五、六、七步都是允许的：insert

行数据批量delete时，InnoDB如何处理自增ID的？这里有一个潜在的大坑。整个实验步骤如上图：第一步：建表，设定自增列；第二步：指定id=1插入，锚定第一行是id是1；第三步：不指定id，依赖自增机制，插入3行；画外音：此时id应该变为2，3，4了？第四步：delete删除所有记录；画外音：坑就容易出在这里。第五步：指定id=0插入；第六步：指定id=1插入；第七步：不指定id，依赖自增机制，插入1行；

人的自我认知，有多少来自别人对你的评价？前几天，从一本经济学的书《怪诞行为学2：非理性的积极力量》里看到一个很有趣的心理学实验，“男女配对实验”，结果很有趣，同时又引人深思，分享给大家。实验组找来100位青春年少的单身大学生，男女各半，其中男生的背后贴上了1，3，5...99这50个数字，而女生的背后贴上了2，4，6...100这50个数字。实验的规则是：（1）每个人只能看见别人的数字，而不知道自己的数字；（2）所有人都可以找一位彼此都中意的异性配对，配对成功后，双方一共可以获得，两人背后数字之和乘以100美元的奖金，如果最后还没有配对成功，则没有奖金；例如，31的男生与58的女生配对成功，两人一共可获得(31+58)*100=8900美金的奖金。（3）可以交流，但不能把对方的数字告诉对方；（4）试验时间有限，必须在1个小时之内完成；这个实验似乎很简单，每个人都去寻找，能和自己凑到最大数字总和的异性，就能拿到最高的奖金。大家猜猜试验结果如何？一开始，由于大家都不知道自己背后的数字，只能去观察别人，于是很快，分数高的人周围都围满了人，所有人都想说服他/她们和自己配成一对。画外音：90+的那些男生和女生。这些天生就自带光环，谁都想和自己配对的男神/女神，虽然不知道自己的数字，但通过别人评价，都变得挑剔起来，于是他/她们也纷纷抱团，在高分的圈子里，相互配对起来，过了不久，90+的男男女女，很快就配对完了。画外音：启示一，很多时候，人的自我认知，来自于别人的评价。接下来，那些碰壁的追求者迫于无奈，只能退而求其次，找90+的人不行，80+也可以，甚至70+或者60+也行。几轮配对下来，基本是同一个范围的数字配对成功，成团的一对，数字差基本不会超过10。画外音：启示二，很多时候，门当户对是有道理的。那些数字偏小的人（例如：个位数）就很悲催了，到处碰壁，到处被拒，到处被嫌弃，在短短的1个小时里感受到了人间的冷暖，要找一个愿意配对的人简直是难上加难。于是，他们开始想办法“整活”了：如果你愿意和我配对，拿奖金的时候，我愿意给你更多，比如三七分或四六分等等，或者事后再请你吃饭。画外音：补充一下，实验所在当地的普适价值观是，奖金事小，如果自己没人看上，会很丢脸，所以大家都想方设法配对成功。这类整活，在现实中的婚姻也一样：付出一些东西，例如房子、财产等，交换所谓的“平衡”。画外音：启示三，很多时候，付出一些东西，才能得到一些东西，以实现所谓的“平衡”。到了最后，时间快要到了，还剩余了几种情况。一种是，大家自己找个差不多的凑合凑合算了，虽然奖金比较少，但也好过没有。一种是，因为人太多地方太小，并不可能跑去看每个人背后的数字，于是在可见选择范围内选择了一个次优的。还有一种，没有配对到自己想配对的人，于是以单身的身份结束了游戏。画外音：启示四，外界压力之下（例如：时间紧迫，被催婚等），有人选择了将就，有人选择了视野范围内最优解，有人选择了坚守信念。这场心理学实验，是人类行为（特别是恋爱行为）的一个缩影：（1）我们会评估别人；（2）我们会根据别人对自己的评估来评估自己；（3）我们会追求门当户对；（4）我们会用整活去追求“平衡”；（5）我们会将就，会追求次优，会坚守信念；我们在生活中所遇到的人远远超过了100个，我们面临的是一个更加复杂的环境，这让我们做出决定的难度成倍增加。正因为选择的难度很大，因此人类进化出了一些很简单的方法，比如，我们更倾向于基于世人的判断来评估自己。这里的世人是谁？就是那些所谓的“大多数人”，是你的邻居老王，是你的三姑六婆，是你的同事同学，甚至是你的亲生父母。很多时候，这个社会的风潮是由这些“大多数人”去决定的，所以当你看到社会的价值倾向时，你看到的就是大多数人的标准。而“人云亦云”就是这些大多数人“发表意见”的最佳策略。作为理性的经济人，这可能没错。但理性的经济人，成就不了罗密欧与朱丽叶，成就不了张生与崔莺莺，成就不了杰克与肉丝这些感人至深的配对。姑娘，有一天一个百万富翁向你求婚，愿意给你一切，算了一下，你以为自己赚了一百万。但同时，假如又有一个千万富翁看上你了，你会损失九百万机会成本。——————这是经济学。我非常庆幸，我的太太经济学没有学好，年轻的时候她非常优秀，我爱她自己却并没有什么钱，但她还是嫁给我了。——————这是爱情。我们的自我认知，来不来自别人的评价，是不是被这些“大多数人”的思潮所裹挟，我们的爱情观，是不是要遵循理性经纪人假设，这些，完全取决于我们自己。共勉！

经常有朋友问，MySQL的InnoDB到底支不支持哈希索引？对于InnoDB的哈希索引，确切的应该这么说：（1）InnoDB用户无法手动创建哈希索引，这一层上说，InnoDB确实不支持哈希索引；（2）InnoDB会自调优(self-tuning)，如果判定建立自适应哈希索引(Adaptive

buffer：（1）不是一个内存buffer，是一个内存/磁盘两层的结构，是InnoDB里On-Disk架构里很重要的一部分；（2）是一个通过写两次，保证页完整性的机制；

可能有水友要问，高并发的业务，InnoDB运用哪种刷盘策略最合适？高并发业务，行业最佳实践，是使用第三种折衷配置（=2），这是因为：（1）配置为2和配置为0，性能差异并不大，因为将数据从Log

changes)，等未来数据被读取时，再将数据合并(merge)恢复到缓冲池中的技术。写缓冲的目的是降低写操作的磁盘IO，提升数据库性能。画外音：R了狗了，这个句子，好长。

参数：innodb_old_blocks_time介绍：老生代停留时间窗口，单位是毫秒，默认是1000，即同时满足“被访问”与“在老生代停留时间超过1秒”两个条件，才会被插入到新生代头部。

2021年，迅猛过去了。今天，给大家做一个分类精选，选取12.31之前发布的，阅读还不错的100篇，大家点击标题，直接阅读。如果之前有错过的文章，这是一个很好的补课机会。这几篇，首先推荐大家读一读：《我们从来都反对“大中台，小前台”的架构设计！》2.1W+《关于MySQL，这篇都没人赞，太没天理了！》1.3W+《关于MySQL异步复制，MGR内核原理！》《求解“微信群覆盖”的三种方法：暴力，染色，链表，并查集》关于底层内核的文章，似乎阅读越来越低了。今年花在开源学习上的时间并不多：《1万行代码，单机50万QPS，今年最值得学习的开源RPC框架！》2.3W+《开源微服务API网关，单核2万QPS，今年最值得学习的开源项目》2W+大家今年阅读开源代码了吗？数据库与缓存，大家应该都用得挺多的：《缓存，你真的用对了吗？》《缓存架构，最佳实践》《缓存与数据库不一致，你遇到过吗？》《数据库主从不一致，你遇到过吗？》《不用缓存服务，还能怎么缓存数据？》1.2W+《选redis还是memcache，源码怎么说？》1.2W+架构解耦，是一个很常见的话题：《系统解耦的四种常见方法》1W+《为什么说，MQ，是互联网架构的解耦神器？》1.1W+《数据库架构，到底设计些什么？》《你的业务代码，是不是都写在了Activity里？》1W+《究竟能不能，不引入数据库中间件？》《IP解耦实践：小小的IP，大大的耦合》《我去，拷贝代码，居然还有这等好处？》《数据库解耦实践，你中招了吗？》1.1W+《明明服务化了，为啥耦合更加严重了？》一些架构实践：《用uid分库，那name上的查询怎么办？》1.4W+《微服务，为何不是越早越好？》《读服务+写服务分离架构，我坚决反对！》1.1W+《服务之间通过缓存传递数据，我坚决反对！》1.2W+《每秒100W次的计数，架构原来可以这样设计！》1W+《群消息已读回执，究竟是推还是拉？》1.6W+《群消息，究竟存1份还是多份？》1W+数据库相关的话题永远受欢迎：《InnoDB并发如此高，原因竟然在这？》2.2W+《数据库索引，终于懂了》2.1W+《InnoDB索引内核设计细节》1.4W+《大坑，MySQL主键与唯一索引约束》1.3W+《InnoDB的七种锁，这次终于懂了！》2W+《InnoDB如何巧妙实现，4种事务的隔离级别》1.1W+《InnoDB调试死锁的方法！（收藏）》《即使删了全库，如何半小时恢复？》1.2W+《MySQL官方的数据库中间件，有人用么？》1.1W+《假如让你，来设计数据库中间件》面试中，有一些经常被问到的问题：《一次搞透，面试中的TopK问题！》《一次搞透，面试中的数1问题的五种方法！》《一次搞透，求最大最小值》《究竟为什么，快速排序的时间复杂度是n*lg(n)》《编程实现“斐波那契数列”的5种方法！》《这个排序这么酷，为什么知道的人很少？》《我学会了这种O(n)的排序算法》《又一个，时间复杂度为O(n)的排序！》几个装13的算法，也算开开眼界：《惊叹！世界上最漂亮的排序算法！》《世界上最奇葩的排序算法！》《长见识了！世界上最慢的排序算法！》1.1W+推荐，广告，搜索都离不开这些算法，很多人觉得很难，用通俗的语言写了写：《老板问我，什么是协同过滤？》《老板问我，什么是基于内容的推荐？》《老板问我，完全没有用户历史行为记录，怎么做推荐？》1.1W+《老板问我，什么是关联规则推荐？》《老板问我，价格歧视是怎么实现的？》1分钟系列，肯定少不了：《MySQL主从之外，你又多了一项选择，Galera》《区块链究竟是啥？》1W+《LF线程模型》《两个广告位，三家广告主，究竟怎么竞价？》《广告，并不是谁出价高，谁排第一！》今年讲职场软技能的文章比较多：《必看！辩论的5点技巧》《究竟如何应对老板需求？》1W+《为啥每次要请示老板，我就会觉得紧张？》1W+《如何精准接收，老板布置的任务？》1.7W+《在职场，要是这么说，等于没说》1.5W+《在职场，千万不要表现得消极》《为何晋升的不是你？》《架构师必备的四种能力，你具备吗？》《究竟是什么，在阻碍我们晋升？》1.2W+《技术人，如何有效的开会？》《在公司做事，为人处世有啥秘诀？》其中，团队管理相关的文章还比较受欢迎：《很多人问，到底要不要转管理？》1.2W+《让开吧，要是我来干，早搞定了》1.7W+《带团队，不要轻易放弃任何一个队友》1.1W+《推下属出去背锅，是最被人不耻的管理者》1.3W+《一个字节跳动人的感悟：如何快速把团队带散》1.6W+《带团队，究竟要不要手把手教？》《不PUA的管理者，需要具备哪5项特质？》《提拔后备干部，主要看哪5点？》1W+还看了一些文章，能引发深度思考，分享给大家：《人到底是为了什么活着？》1.5W+《一个百度员工的离职感悟：我以为，我永远不会成为一个好员工》1.9W+《滴滴研究院：通过大数据监测国家各部委出行规律》3.9W+《人生很长，长期来看，你的好人品终将保护你》《没钱就是没钱，那不是吃苦》1W+《成年人的崩溃，往往就是从无数“不理解”累积起来的》读书会的活动再继续，有一些好书推荐给大家：《如何成为一个很厉害的人？》1.9W+《时间很贵，别轻易浪费（马化腾作序）》1.5W+《我，是如何度过人生最艰难的时刻的》22年，自己也一定要坚持读书。今年，尝试用视频号创新讲技术了，大伙能接受吗：《新垣结衣发新片了，系统要扩容多少才能抗住？》3.9W+《架构师究竟如何进行容量预估？》1.5W+《假如P站流量涨了10倍，集群要扩容几倍呢？》1.1W+《究竟什么是反向代理？》1.5W+《究竟什么是DAO？》2W+《第三方组件，究竟为什么一定要封装一层？》1.2W+《究竟什么是“针对晋升”的技术选型？》1.9W+《究竟什么是ALL

总结数据库主库和从库不一致，常见有这么几种优化方案：（1）业务可以接受，系统不优化；（2）强制读主，高可用主库，用缓存提高读性能；（3）在cache里记录哪些记录发生过写请求，来路由读主还是读从；

为什么会出现这类不一致？可以看到，这里提到的缓存与数据库数据不一致，根本上是由数据库主从不一致引起的。当主库上发生写操作之后，从库binlog同步的时间间隔内，读请求，可能导致有旧数据入缓存。

Pattern”？旁路缓存方案的经验实践，这个实践又分读实践，写实践。画外音：与旁路缓存对应的，是穿透缓存。读实践是怎么样的？对于读请求：（1）先读cache，再读db；（2）如果，cache

缓存，是互联网分层架构中，非常重要的一个部分，通常用它来降低数据库压力，提升系统整体性能，缩短访问时间。有架构师说“缓存是万金油，哪里有问题，加个缓存，就能优化”，缓存的滥用，可能会导致一些错误用法。4类缓存常见误用，你中招了吗？误用一：把缓存作为服务与服务之间传递数据的媒介。如上图：（1）服务1和服务2约定好key和value，通过缓存传递数据；（2）服务1将数据写入缓存，服务2从缓存读取数据，达到两个服务通信的目的；该方案存在的问题是：（1）数据管道，数据通知场景，MQ更加适合；（2）多个服务关联同一个缓存实例，会导致服务耦合；误用二：使用缓存未考虑雪崩。常规的缓存玩法，如上图：（1）服务先读缓存，缓存命中则返回；（2）缓存不命中，再读数据库；什么时候会产生雪崩？如果缓存挂掉，所有的请求会压到数据库，如果未提前做容量预估，可能会把数据库压垮（在缓存恢复之前，数据库可能一直都起不来），导致系统整体不可服务。如何应对潜在的雪崩？提前做容量预估，如果缓存挂掉，数据库仍能扛住，才能执行上述方案。否则，就要进一步设计，更具体的，有两类常见方案。方案一：高可用缓存如上图：使用高可用缓存集群，一个缓存实例挂掉后，能够自动做故障转移。方案二：缓存水平切分如上图：使用缓存水平切分，一个缓存实例挂掉后，不至于所有的流量都压到数据库上。误用三：调用方缓存数据。如上图：（1）服务提供方缓存，向调用方屏蔽数据获取的复杂性（这个没问题）；（2）服务调用方，也缓存一份数据，先读自己的缓存，再决定是否调用服务（这个有问题）；该方案存在的问题是：（1）调用方需要关注数据获取的复杂性；（2）更严重的，服务修改db里的数据，淘汰了服务cache之后，难以通知调用方淘汰其cache里的数据，从而导致数据不一致；（3）有人说，服务可以通过MQ通知调用方淘汰数据，额，难道下游的服务要依赖上游的调用方，分层架构设计不是这么玩的；误用四：多服务共用缓存实例。如上图：（1）服务A和服务B共用一个缓存实例（不是通过这个缓存实例交互数据）；该方案存在的问题是：（1）可能导致key冲突，彼此冲掉对方的数据；画外音：可能需要服务A和服务B提前约定好了key，以确保不冲突，常见的约定方式是使用namespace:key的方式来做key。（2）不同服务对应的数据量，吞吐量不一样，共用一个实例容易导致一个服务把另一个服务的热数据挤出去；（3）共用一个实例，会导致服务之间的耦合，与微服务架构的“数据库，缓存私有”的设计原则是相悖的；建议的玩法是：如上图：各个服务私有化自己的数据存储，对上游屏蔽底层的复杂性。总结缓存使用小技巧：（1）服务与服务之间不要通过缓存传递数据；（2）如果缓存挂掉，可能导致雪崩，此时要做高可用缓存，或者水平切分；（3）调用方不宜再单独使用缓存存储服务底层的数据，容易出现数据不一致，以及反向依赖；（4）不同服务，缓存实例要做垂直拆分；这些坑，你踩过吗？架构师之路-分享可落地的技术文章相关文章：《架构师之路，20年干货精选》

temp;}很容易发现，由元素找集合根的时间复杂度是树的高度，即O(lg(n))。有没有更快的方法呢？进一步思考，为什么每个节点要指向父节点，直接指向根节点是不是也可以。更具体的：element{

价格歧视，是用户非常反感的：（1）相同起点，相同终点的两个手机打车，价格不一样；（2）相同的起点，相同终点的两个用户买飞机票，机票价格不一样；这么粗暴实现，容易被舆论推上风口浪尖。目前的常见玩法，是大家看到的价格都一样，但系统推荐的优惠券不同。今天花1分钟，通俗的说说此类“个性化优惠券”是如何实现的。方式一：“用户分级”。对用户进行分级，不同类型的用户会有不同的补贴，定价，营销策略。以网约车用户为例，不同用户的营销策略不同。待拉新用户：（1）竞品用户：短信发大额优惠券营销；（2）竞品重合用户：短信发优惠券营销；（3）沉默用户：定额微信红包唤醒；首单用户：大额折扣券或者直减券。非首单用户：（1）2单用户：降低优惠券金额试探；（2）3单用户：降低优惠券金额试探；（3）疑似粘性用户：随机优惠券试探；（4）强粘性用户：意思意思优惠券；所以，对于“相同起点，相同终点的两个手机打车”，可能出现：（1）新客新手机优惠高；（2）熟客老手机优惠少；方式二：“个性化推荐”。对用户的历史行为进行分析，抽象用户的标签，针对不同标签的用户进行不同的补贴，定价，营销策略。例如平台可以从日志中分析出用户A的历史特征是：（1）有优惠券也不使用；（2）等待30秒没人接单就加价；（3）等待60秒没人接单就打专车；可以分析出：用户A是土豪，对接单时间敏感，对价格不敏感。从日志中分析出用户B的历史行为特征是：（1）没有优惠券就不下蛋；（2）宁愿等待10分钟也不加价；（3）从不打专车，也绝不在高峰期(价格会加倍)打车；可以分析出：用户B是屌丝，对价格敏感，以省钱为优先。于是，用户A和用户B同时打车，可能出现：（1）时间敏感的用户A，优惠少；（2）价格敏感的用户B，优惠多；从历史数据，一定能还原出真实的你，“杀熟，杀豪”是个性化价格的两大利器，但大伙坚决不能这么干哟！架构师之路-分享可落地的技术文章相关文章：《架构师之路，20年干货精选》《老板问我，什么是协同过滤？》《老板问我，什么是基于内容的推荐？》《老板问我，没有历史行为记录，怎么做推荐？》《老板问我，什么是关联规则推荐？》调研：hello，土豪，你被杀过吗？

又发现一个不错的，工业级的，高性能RPC框架srpc，分享给大家。（1）RPC简介；（2）行业常见RPC框架；（3）srpc特点；（4）srpc上手指南，demo示例；（5）srpc架构设计；（6）srpc相关资料与资源；文章较长，建议提前收藏。什么是RPC？Remote

工程架构方向的程序员，看到推荐/搜索/广告等和算法相关的技术，心中或多或少有一丝胆怯。但认真研究之后，发现其实没有这么难。今天给大家介绍下推荐系统中的“关联规则推荐”，保证大伙弄懂。画外音：可以看excel截图，或者看公式，大伙结合自己能够理解的程度自取。一、概念什么是关联规则（Association

文章较长，从概念与场景，到原理与架构，到性能分析，最后是demo，希望大家有收获。第一部分：解决什么问题。什么是微服务API网关？API网关是上承前端用户，下接后端服务的咽喉之地，是所有客户端请求响应出入流量的必经之路。微服务API网关有什么用？它除了可以做最基础的反向代理之外，还可以处理通用的公共服务逻辑，如负载均衡、灰度发布、限流熔断、统一认证授权、可观测性、动态路由、协议转换、服务编排、流量镜像、健康检查、监控报警、安全防御等等等等。说得这么抽象，有没有具体的场景呢？对应到具体场景，举几个常见的例子。场景一：负载均衡。当服务器负载上升时，需要立即对系统资源进行容量评估，适当增加扩容服务器资源，让每台服务器可以平均承载分担请求压力，此时应该采用何种负载策略：轮询、随机还是哈希？如果你有API网关，在后台配置好，即可自动实现。场景二：灰度发布。上了一个新功能，需要每天自动放

Recommendation），但都必须分析用户的历史行为数据（例如电影点击数据，职位查看数据等），针对不同的用户进行个性化推荐。老板问我，如果系统没有用户的历史行为数据积累，就不能实施推荐了吗？

工程架构方向的程序员，看到推荐/搜索/广告等和算法相关的技术，心中或多或少有一丝胆怯。但认真研究之后，发现其实没有这么难。今天给大家介绍下推荐系统中的“基于内容的推荐”，绝无任何公式，保证大伙弄懂。什么是基于内容的推荐（Content-based

工程架构方向的程序员，看到推荐/搜索/广告等和算法相关的技术，心中或多或少有一丝胆怯。但认真研究之后，发现其实没有这么难。

最烦面试官问，“为什么XX算法的时间复杂度是OO”，今后，不再惧怕这类问题。快速排序分为这么几步：第一步，先做一次partition；partition使用第一个元素t=arr[low]为哨兵，把数组分成了两个半区：左半区比t大右半区比t小第二步，左半区递归；第三步，右半区递归；伪代码为：void

如何从n个数里找到最大值与最小值？很容易想到，用一个循环找到最大值和最小值，就能搞定。

抱歉，我机器太慢，算不出来额滴神哪，不是骗我吧！！！画外音：（1）这个count，是函数递归了对少次；（2）f(45)，机器居然算不出来；（3）对结论有疑问的，自己可以run一把；

内存分析：被分析的整数变成uint16，打表数组需要记录2^16个正整数的结果。n1和n2的二进制表示最多包含16个1，存储结果的计数，使用4个bit即可。故，共需要内存2^16

前段时间，分享了《算法导论》中，时间复杂度为O(n)的三种排序：《这个排序酷，O(n)》《这个排序靓，O(n)》《这个排序跩，O(n)》一个代码极具美感的最美排序：《世界上最美的排序算法！》以及一个只具有分析意义的最慢排序：《世界上最慢的排序算法！》然后有水友在评论中留言“是不是下一期要讲睡眠排序了？”。楼主才疏学浅，没有听过“睡眠排序”，网上搜了一下，眼界大开。这是一个不但没有工程意义，也不具有分析意义，甚至未必能得到正确的排序结果的排序。既然大伙充满好奇心，那就简单分享一下。话不多说，先上伪代码：void

前段时间，分享了《算法导论》中的一些排序算法。最美排序：《世界上最美的排序算法！》时间复杂度为O(n)的三种排序：《这个排序酷，O(n)》《这个排序靓，O(n)》《这个排序跩，O(n)》今天，和大家分享一个，世界上最慢的排序算法，猴子排序（bogo

希望这一分钟，大家有收获。架构师之路-分享可落地的技术文章推荐阅读：《这一种O(n)的排序算法》《这个排序这么酷，为什么知道的人很少？》《世界上最漂亮的排序算法！》

计数排序的空间复杂度？计数排序需要一个辅助空间，空间大小为O(MAX-MIN)，用来存储所有元素出现次数（“计数”）。画外音：计数排序的核心是，空间换时间。

希望这一分钟，大家有收获。架构师之路-分享可落地的技术文章推荐阅读：《世界上最漂亮的排序算法！》《一次搞透，面试中的TopK问题！》调研：你知道哪些排序算法，时间复杂度是O(n)吗？

由代码很容易看出来：（1）当只有1个元素时，完美排序的时间也是1；（2）当有n个元素时，完美排序由一个常数计算，加上三次递归，每次递归数据量为(2/3)*n；

来源：知乎原问题：31岁了在家喝个可乐还要被骂是什么体验？原回答：https://www.zhihu.com/question/381481028/answer/1103034393我认识一个人，他酷爱橘子蛋糕。累了，就去买一小块橘子蛋糕，咬下去时他的表情是放松的。他很忙，忙于工作，忙于讨好上司，忙于养房子，忙于车贷。唯一开心的事就是回到家，躺在沙发上，吃一口橘子蛋糕。他的父母反对他吃橘子蛋糕，"因为橘子蛋糕有糖分，会导致蛀牙！"他的父母说。每当他吃橘子蛋糕时，他的父母都会闲上一嘴："多大的人了，还吃橘子蛋糕？小孩子才爱吃甜的东西！"这话是谁都不爱听的，我爱吃什么你们为什么要管呢？他的父母还是反对，反对他吃橘子蛋糕。从一开始的小声嘀咕，到后面的大吵大闹，再到掀桌子，把橘子蛋糕丢出窗外。他看在眼里，却又不知道怎么反抗。因为只有小孩子才会反抗——而他已经是踏入社会的社会人了。今天也是一样，忙碌了一天，被上司臭骂，又被炒鱿鱼。他拖着自己的躯壳回到家打开冰箱，原本放在那里的橘子蛋糕不翼而飞——而关上冰箱后站在身边的父亲和他说："你的蛋糕我已经扔了，成熟点，谁没点压力呢？别这么脆弱。"父亲的话，轻轻描出他的委屈他的压力，又将它们重重地拍在地上，语重心长地说，"别这么脆弱。"他的脑海里像放映室一样放着电影——那些本该忍住的委屈，那些本该由"成熟的人""理应"去承受的压力。从片头，到片尾，漫长，痛苦。而回过神，他早已在楼与楼之前，高速坠落。"都怪橘子蛋糕！把我孩子害成这样！没有橘子蛋糕我家孩子什么事都没有！！我这么辛苦养他！他怎么就是不理解我呢！！"他的父亲在记者的摄像机前以泪洗面。==【全文完】==你怎么看？推荐：《一次搞透，面试中的TopK问题！》

这个partition是干嘛的呢？顾名思义，partition会把整体分为两个部分。更具体的，会用数组arr中的一个元素（默认是第一个元素t=arr[low]）为划分依据，将数据arr[low,

区块链，比特币这些概念很火，但很多人搞不清楚它究竟是啥，从技术的角度，从架构的角度，用通俗的语言谈谈楼主的理解。究竟啥是区块链？一句话，区块链是一个存储系统。更细一点，区块链是一个没有管理员，每个节点都拥有全部数据的分布式存储系统。通常所见的存储系统是啥样的？如上图，一块空间存储数据，一个软件管理数据，提供接口写入数据，这是存储系统，例如mysql。普通的存储系统会有什么常见的问题？常见的有两个问题：（1）数据存在一个地方很危险，空间损坏数据就丢了，用技术的话说即“数据不高可用”；（2）写入点只有一个，用技术的话说即“单点控制”；如何保证数据高可用？解决高可用要“冗余”，如上图，如果能把数据冗余到多个地方，就能保证高可用，一个地方的数据挂了，另外的地方仍存有数据。例如mysql主从集群，以及磁盘的RAID都是这个原理。这里需要强调两点：（1）数据冗余往往会引发一致性问题，例如mysql主从集群中的读写延时问题；（2）数据冗余往往会降低写入效率，因为同步数据需要消耗额外的资源；可不可以多点写入？可以。可以多个节点都实施写入，例如mysql双主集群，又或者多机房多活数据中心。这里要强调的是，多节点写入往往会引发写写冲突的一致性问题。多点控制写入之后，其实出现了多中心控制，在数据不一致的时候，往往需要有一个算法来协商如何处理不一致数据。例如，存在两个中心节点时，可以约定这样的算法来处理不一致：（1）以时间戳最小的数据为准，即先来先得；又例如，存在多个中心节点时，可以约定这样的算法来处理不一致：（2）投票，以多数票的数据为准；什么是区块链？（1）区块是一块存储空间，可以存储数据；（2）区块链不但像链表一样把区块串起来，还有约定了一系列的方法管理这些数据，所以它是存储系统；（3）区块链有很多节点，每个节点都保存了全部的数据，所以它是高可用的；（4）每一个中心节点都可以生成区块，并写入数据，所以每一个点都是中心节点，或者说区块链是去中心化的，要想控制整个系统，必须控制一半以上的节点，才能控制投票，于是这个系统没有管理员；综上，区块链实际上是一个没有管理员的，去中心化的，每个节点都拥有全部数据的分布式存储系统。只要你愿意，你随时可以成为区块链中的一个节点，并参与区块的生成与写入，比特币就是基于这个分布式存储上的电子货币。由于节点很多，很多数据需要同步，这个系统的存储容量其实不大，目前全球存储比特币的区块链也就100多G。画外音：额，有朋友说他们公司的mysql数据库轻轻松松几百G。因为节点很多，数据需要保持一致，这个系统的写入效率也很低，存储比特币的区块链每10分钟才生成1个区块，1个区块只有1M的存储空间，只够写入2000笔比特币交易的数据。画外音：比特币全球交易，每10分钟只能处理2000笔交易。有朋友说他们公司自研的存储系统轻轻松松；每秒处理交易10W笔。关于区块链，本文只说了概念，作为一个存储系统，数据的生成，写入，管理，数据一致性，数据冲突处理方法，数据完整性保证…很多细节未来再用“通俗技术性文字”和大家分享。希望这一分钟，大家有收获。推荐文章：《关于MySQL，PXB核心原理！》《MySQL主从之外，你又多了一项选择，Galera》《为什么MySQL要升级组复制，MGR？》

Replication），是互联网公司用的最多的数据复制与数据库集群化方法，它的思路是，从库执行串行化后的主库事务。其核心原理如上图所示：（1）第一条时间线：主库时间线；

绝大部分互联网公司，都使用MySQL的InnoDB引擎存储数据。为了保证数据库的高可用，为了保证性能的扩展，绝大部分公司又会使用主从同步，读写分离的MySQL集群架构。传统的主从同步，读写分离MySQL集群架构如上图所示：（1）主库：左侧第一个实例，提供写服务的实例；（2）从库：右侧两个实例，提供读服务的实例；此时数据复制是如何实现的呢？仍如上图所示：（1）客户端将写操作提交给主库；（2）Replication：主库将操作序列化，通过binlog的方式传输给从库；（3）从库执行相同序列的操作，以实现副本冗余；传统的主从同步，读写分离冗余模式，数据库集群存在什么问题呢？（1）用户要关注集群细节，实施读写分离；（2）写库仍是单点，性能无法线性扩充；（3）读库有延时，数据不一致；（4）写库挂了，从库顶上，可能出现数据丢失；（5）如果引入中间件，SQL能力会受影响；（6）运维复杂性；（7）…既然这么多痛点，有没有一项技术，能够解决大家的问题呢？Galera集群（Galera

13年底，负责数据库中间件的设计，当时的设计文档，拿出来和大家分享：（1）可以了解下数据库中间件技术；（2）可以了解下架构师系统设计的思路；画外音：后面项目没落地。一、总体目标数据库中间层项目背景不再展开，根据前期的调研以及和公司同事的讨论，中间层的核心目标主要有两个：（1）db虚拟化：让db对业务线透明（本文的db均指mysql），业务线不再需要知道db的真实ip，port，主从关系，读写关系，高可用等；（2）无限容量（分库）的支持：让db的分库对业务线透明；二、实现的功能上述目标相对比较宽泛，具体来说，数据库中间层需要实现以下功能。（1）统一接入入口如果统一接入入口，从今以后，不再有db1.58.com:3306db2.58.com:3306im.58.com:3306jiaoyou.58.com:3306而只有db.58.com:3306所有的业务线，对db的访问，都只有一个入口，由数据库中间层来进行权限验证，由中间件来路由请求，这是一种完美的情况。

新尝试，视频号聊技术，欢迎双击爱心新尝试，60s分享一个正能量。“架构师之路”视频号，能学技(duan)术(zi)的视频号如果大家喜欢，我尽量坚持下去。推荐文章：《关于MySQL，这篇都没人赞，太没天理了！》

新尝试，视频号聊技术，欢迎双击爱心新尝试，60s分享一个正能量。“架构师之路”视频号，能学技(duan)术(zi)的视频号如果大家喜欢，我尽量坚持下去。推荐文章：《关于MySQL，这篇都没人赞，太没天理了！》

log是一个512字节的数据块(block)，这个数块由12字节的header，508字节的body，4字节的trailer组成，body里保存的就是上述数据页如何进行修改的记录。记录redo

什么是耦合？耦合，是架构中，本来不相干的代码、模块、服务、系统因为某些原因联系在一起，各自独立性差，影响则相互影响，变动则相互变动的一种架构状态。感官上，怎么发现系统中的耦合？作为技术人，每每在心中骂上下游，骂兄弟部门，“这个东西跟我有什么关系？为什么需要我来配合做这个事情？”。明明不应该联动，却要被动配合，就可能有潜在的耦合。

新尝试，视频号聊技术，欢迎双击爱心新尝试，60s分享一个正能量。“架构师之路”视频号，能学技(duan)术(zi)的视频号如果大家喜欢，我尽量坚持下去。推荐文章：《每秒100W次的计数，架构这样设计》《数据库软件架构，到底要设计些什么》《一个库里Curry几百个表，这谁受得了？》

什么是耦合？耦合，是架构中，本来不相干的代码、模块、服务、系统因为某些原因联系在一起，各自独立性差，影响则相互影响，变动则相互变动的一种架构状态。感官上，怎么发现系统中的耦合？作为技术人，每每在心中骂上下游，骂兄弟部门，“这个东西跟我有什么关系？为什么需要我来配合做这个事情？”。明明不应该联动，却要被动配合，就可能有潜在的耦合。

随着业务越来越复杂，数据量越来越大，并发量越来越大，数据库的性能越来越低。好不容易找运维申请了两台机器，让DBA部署了几个实例，想把一些业务库拆分出来，却发现一个库里几百个表，拆不出来，扩不了容，尴尬！