数据集成派生数据与分布式事务通过不同的方式达到了类似的目标。分布式事务通过锁机制进行互斥来决定写操作的顺序，而CDC和事件源使用日志进行排序。分布式事务使用原子提交来确保更改只生效一次，而基于日志的系统通常基于确定性重试和幂等性。派生数据允许逐步演变。想重建数据集，无需采用高风险的陡然切换。而是在同一个基础数据上的两个独立视图来同时维护新老两种架构。逐步将少量用户迁移到新视图中，以测试性能检测错误。最后，所有用户迁移完，放弃旧视图。lambda架构核心思想是将数据看成一个个不可变的事件，基于这些总事件，派生出读优化的视图。建议运行两套系统：一个批处理，一个流处理。批处理产生精确的全量视图，流处理产生及时的增量视图。这样结合了两套系统的优点：批处理简单，不易出错，流处理不可靠，难以容错，但流处理可以使用快速的近似算法。最近的发展是将批处理和流处理在同一个系统中实现，即所谓的kappa架构。分拆数据库整个组织的数据流就像一个巨大的数据库。每当批处理、流或ETL将数据从一个位置传输到另一个位置，就类似数据库子系统需要保持索引或实体化视图至最新状态。流处理，批处理就像触发器。没有统一的数据模型或存储格式适用于所有的访问模式，最终会统一为两种途径：联合数据库：统一读端为各种各样的底层存储引擎和处理方法提供一个统一的查询结构：一种称为联合数据库或聚合存储的方法。分离式数据库：统一写端跨系统的同 ...继续阅读 (62)

一个可用的复杂系统总是从可用的简单系统演进来的。反过来这话也是正确的：从零开始设计的复杂系统从来都用不了，也没办法把它变成可用。——John Gal，《系统学》（1975）发送事件流消息系统发送事件通知的常用方式。如果生产者发送消息的速度快于消费者处理，会发生什么？如果节点崩溃或暂时离线，是否会有消息丢失？生产者与消费者直接消息传递即无代理的方式。这种方式当消费者离线时会丢失消息。常见场景：UDP组播广泛应用在金融行业，比如股票市场等低延迟场景。无代理的消息库，如ZeroMQ和nanomsg，通过TCP或IP多播实现发布/订阅消息传递。StatsD和Brubeck使用UDP手机网络中所有机器的指标并进行监控。网络上公开服务，生产者直接发出HTTP或RPC请求将消息推送给消费者。消息代理（无日志）本质上是一种针对消息流处理而优化的数据库。常见产品Rabbit MQ、ActiveMQ等。只能消费订阅之后的消息，也就是历史的消息已经不能消费了。基于日志的消息存储将历史的消息存储为日志形式。代表产品Kafka、Twitter DistrbutedLog。数据库与流事件是成功的命令。一个请求到来时最初是一个命令，它可能失败，或违反某种约束。一旦它成功，它就是一个事件了。变更数据捕获（changed data capture，CDC）是一种设计理念。不是记录数据的当前状态，而是数据变化的过程。 ...继续阅读 (63)

宁国公（长子）贾代化（长子）贾敷（长子，早夭）贾敬（次子）贾珍x尤氏贾蓉（儿子）x秦可卿贾蔷（侄子）贾惜春贾代儒贾瑞父母（亡故）贾瑞（孙子）荣国公（次子）贾代善（长子）x史太君贾赦（长子）x邢夫人贾琏x王熙凤贾迎春x孙绍祖贾政（次子）x王夫人+周姨娘+赵姨娘贾珠（长子，早夭）x李纨贾兰贾元春（长女）贾宝玉（次子）贾探春（庶女，母赵姨娘）贾环（庶子）贾敏x林如海林黛玉史家史太君史鼐（内侄）史湘云（侄女）王家王公王子腾王夫人薛姨妈凤姐之父王仁王熙凤薛家薛公宝钗祖父薛宝琴之父薛宝琴薛蝌薛宝钗之父x薛姨妈薛蟠薛宝钗 ...继续阅读 (61)

通过弄清数据的来龙去脉，来理清复杂的系统架构，是本书的宗旨。三种系统：在线服务（或称在线系统）服务等待客户端请求或指令的到达。当收到请求或指令时，服务试图尽快的处理它，并发挥响应。响应时间和可用性是衡量标准。批处理（或称离线系统）接收大量的输入数据，运行一个作业来处理数据，并产生输出数据。衡量标准是吞吐量。流处理（或称近实时系统）流处理介于在线与离线之间。与批处理类似，流处理处理输入并产生输出。但是，流处理作业在事件发生不久就可对事件进行处理。linux命令是单机版的批处理，map-reduce是分布式的批处理。unix工具使用stdin和stdout作为输入输出，MapReduce作业使用HDFS（Hadoop Distributed File System）分布式文件系统读写文件。除HDFS外，还有GlusterFS和Quantcast File System（QFS）。注入Amazon S3，Azure Blob存储和Open Swift对象存储服务也有相似之处。HDFS在每台机器上都有一个守护进程，并开放一个网络服务以便其他节点访问存储在该机器上的文件。名为NameNode的中央服务器会跟踪哪个文件存储在哪台机器上。批处理的输出：生成搜索索引。尽管如今Google不再使用MapReduce构建索引，但是MapReduce仍是构建Lucene和Solr的好方法。构建机器学习系 ...继续阅读 (64)

一致性保证分布式一致性与事务隔离级别有相似之处。但总体有着显著区别：事务隔离是为了处理并发执行事务时的各种临界条件，而分布式一致性则主要针对延迟和故障等问题来协调副本之间的状态。可线性化所谓线性化，就是让一个系统看起来好像只有一个数据副本，且所有操作都是原子的。可线性化是最强的一致性保证。例如一个非线性化的体育网站。Alice和Bob坐在同一个房间里各自观看自己的手机，焦集的等待2014年FIFA世界杯决赛的结果。Alice率先看到了比赛结果，然后兴奋地告诉了Bob。结果，Bob刷新之后发现比赛还没有结束。对于Dynamo风格的数据库，即时使用了严格的quorum（法定人数），在网络条件不好的情况下仍然不满足线性化。比如x初始值为0，写客户端向三个副本（n=3，w=3）发送写请求将x更新为1。客户端A在一个节点读到了新值1，客户端B在A读取之后读取，反而收到的都是旧值0。CAP理论不仅仅主从复制和多主复制，即使在一个数据中心内部，只要有不可靠的网络，都会发生违背线性化的风险。CAP理论由Eric Brewer于2000年正式命名，最初是作为一个经验法则被提出，并没有准确的定义，它的含义是“在网络分区的情况下，选择一致性还是可用性”，目的是帮助大家探讨数据库设计的权衡之道，对于具体的系统设计来说意义不大。如果要求线性化，由于网络方面的问题，某些副本断开之后，就必须等待网络修复，或者直 ...继续阅读 (68)

对于大型分布式系统，部分组件失效几乎是一定的。不可靠的网络分布式系统故障或部分失效的一大原因。检测故障检测故障没有什么万能的方法，如果能收到响应，通常使用各种状态码标识，另一些情况下通用的办法就是超时了。超时与无限期的延迟超时成因：负载过重，排队。CPU繁忙。虚拟机环境切换。TCP流量控制（也称拥塞消除，或背压）。TCP与UDPUDP不支持流量控制也不支持重传丢失的数据包，速度较快。如果延迟或丢失的数据价值不大，UDP是一个不错的选择。比如IP电话，应用程序会采用静音填充丢失的位置（出现短暂声音中断）。超时设置长了或短了都不好。更好的方法是自动调整，比如Phi Accrual故障检测器，已经在Akka和Cassandra中使用。TCP重传也采用了类似的机制。同步与异步网络固定电话网在打电话时会动态建立一条电路：一个固定的、带宽有保证的通信链路，这种网络本质是同步的，不会受到排队的影响。由于没有排队，网络最大的端到端延迟是固定的。我们称之为有界延迟。究其根本是目地不同，电话网线路持续时间短，要求及时性，而以太网追求资源的最大化利用。有了这个目的以太网才采用了分组交换协议，这样可以最大化的利用带宽：带宽小的时候我就传少点，带宽大的时候我就传多点。简言之，网络中可变延迟并不是一种自然规律，只是成本与收益相互博奕的结果。不可靠的时钟计算机内部至少有两种时钟：墙上时钟（或称钟表时间）和单调时 ...继续阅读 (63)

29号请了一天假，1号回来的，总共玩了三天。第一天 城墙-鼓楼-回民街-洒金桥-钟楼29号上午12点到的，去酒店旁边的澄城水盆羊肉吃了个水盆羊肉套餐，也许是饿了，味道是真不错，最后连汤都喝干净了。稍微休整了下，我们就奔城墙而去了。查了下距离，离得不远，也就一公里多，我们就走着过去了。从永宁门买的票，到长乐门下来的，走了整个城墙的小1/4圈。顺便提一句，碑林也在永宁门附近，不过我们没去。没骑自行车是因为有小孩，自行车只有单人和双人。当天人不多，或许是还没放假。城墙的一半被围起来了，看着里面在扎花灯。从长乐门下来后，我们一路又走到了回民街。回民街其实相当于北京的南锣鼓巷，就是一条小吃街，只不过比南锣鼓巷要大。我们大概是晚上7点到的回民街，人也不多。尝了尝桂花糕和烤串，烤串和北京回民烤串差不多，都是外面裹一层东西再烤。桂花糕我觉得桂花太少了，几乎没有桂花味。其他小吃如肉夹馍、凉皮、泡馍之类没啥欲望，在北京或多或少都吃过。看网上说洒金桥是当地人比较喜欢去的小吃街，我们一路又转到洒金桥。离回民街不远，大概一公里。在这吃到了在家尝试过的粉蒸牛肉。和自己做的相比，他的味道花椒茴香味比较浓，面比较散，不像自己做的面是黏的 但是他的肉比较硬。总之，吃起来并没有网上视频说的那么惊艳。最后从洒金桥又走到了钟楼。本来想打车的，但是所到之处都是一些小街小巷，怕出租车不好进。在这扫了一个共享单车，推着孩子一路 ...继续阅读 (57)

最初的动机其实一直对体重都没怎么注意过，男的嘛，对自己身材没那么在意，只是每年买的裤子到下年就不能穿了，浪费了不少钱（笑）。直到上年年底体检，体检报告上有一项“超重，脂肪肝（中）”，着实还是给了我一点小小的震撼。以往的体检顶多是“甘油三酯高，转氨酶高”，现在好家伙都发展成中度脂肪肝了。我当时BMI已经超过25，体重一度逼近160。为了“为祖国健康工作五十年”的宏伟目标，我决心要把这个肥给减下去。取得的成果今年一年跑步历程。今年一年体重变化。之前异常的指标去年今年对比。指标20222023参考值体重78.571.7–甘油三脂4.241.640.45~1.70丙氨酸氨基转移酶52290~50γ-谷氨酰转移酶783510~60算下来，瘦了没几斤，但是效果非常显著。就连连续几年一直居高不下的甘油三酯和两个转氨酶也头一次正常了，这真的意想不到。虽说这次跑步的初衷是减肥，但收获不止于此，还收获了一个附属品——恒心，所谓“一事有恒，万事渐振”。朋友都说没之前臃肿了，人的精神状态也变好了。采取的行动我比较懒散，因此也没制定计划。因为根据以往的经验，计划对我来说非但不会让我坚持下去可能还有反作用。每天想跑就跑，实在哪天不想跑，就不跑。其次呢，就是晚饭不吃正餐，吃点水果。但是呢，哪天如果实在饿，也吃晚饭。也不计算卡路里摄入量这些东西，主打就是一个随性和佛系。有人说，不吃晚饭我饿呀，饿的睡不着。你别说， ...继续阅读 (74)

深入理解事务事务将多个读写操作捆绑成一个逻辑整体，要么都成功，要么都失败。ACID原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。BASE基本可用性(Basically Available)，软状态（Soft state）和最终一致性（Eventual consistency）。各家数据库所实现的ACID并不尽相同，更像是一个市场营销用语。BASE是另一套标准，同样模棱两可，唯一可以确定的是“它不是ACID”。原子性要么成功，要么失败，不能部分成功部分失败。在ACID的语境中，指的是出错时终止事务，并将部分完成的写入丢弃。一致性一致性是指对数据有特定的预期状态（满足特定的约束），比如银行贷款和借款余额保持相等。一致性是应用层提供的属性，其他三个是数据库应提供的属性。隔离性并发执行的多个事务互相隔离，不能交叉。多个事务执行的效果和串行执行一样，但内部实现不要求一定串行执行。下面的例子中，用户1和用户2分别更新同一个对象，最终结果本来应该为44，现在是43。由于没有隔离，导致用户1的更新丢失。持久性提供一个安全可靠的地方存储数据而不用担心数据丢失。在计算机语境下常常指写入磁盘。单对象与多对象事务操作单对象事务，比如向数据库写入20KB的JSON文档，多对象事务，比如外键的更新，二级索引的更新等。弱隔离级别所谓 ...继续阅读 (80)

面对海量数据集或非常高的查询压力，光有副本还不行，还需要将数据拆分为分区，也称为分片。事实上，分区和副本常常结合起来使用，来提高系统的扩展性和可用性。分区方式分区的目标是将数据和查询负载均匀分布在所有节点上。如果分区不均匀，那就会出现某些分区比其他分区承担更多的数据量或查询负载的情况，称之为倾斜。极端情况下，所有的负载可能集中在一个分区上，这种严重不成比例的分区即成为系统热点。避免热点的一个简单方法是随机分配，但是它的缺点是读取数据时，只能并行查询所有节点。基于关键字区间分区为每个分区分配一段连续的关键字或关键字范围。比如对于一个保存网络传感器数据的应用系统，选择测量的时间戳（年-月-日-时-分-秒）作为关键字，此时区间查询非常有用，可以快速查询某个月份的所有数据。缺点是某些访问模式会导致热点。比如上面的例子，每天对应一个分区，数据写入时，所有的写入都会集中在一个分区，而其他分区处于空闲状态。解决方案可以在时间戳前面加上传感器名称为前缀。基于关键字哈希值分区一个好的哈希函数可以处理数据倾斜。一旦找到合适的哈希函数，就可以为每个分区分配一个哈希范围。Cassandra和MongoDB使用MD5，Voldmort使用Fowler-Noll-Vo。许多语言也内置简单的哈希函数，比如Java的hashCode，但是要谨慎使用，因为同一键在不同进程中可能返回不同的哈希值。哈希分区的缺点是丧失 ...继续阅读 (69)

本章主要介绍数据复制的技术，问题及挑战，解决方案。复制或多副本技术的意义：高可用：避免单点故障。低时延：将数据放置在靠近用户的地方，从而实现更快的交互。扩展性：采用多副本读取，提高系统的吞吐量。主从复制（一主多从）最主流的复制方案，许多关系数据库都内置支持主从复制，包括PostgreSQL（9.0版本之后）、MySQl、Oracle Data Guard和SQL Server的AlwaysOn Availability Groups，非关系数据库如MongoDB、RethinkDB和Espresso也支持主从复制。还有一些分布式队列如Kafka和RabbitMQ都支持。同步复制和异步复制同步复制的好处是一旦向用户确认，复制已经完成了，缺点是阻塞所有的写操作。异步复制就反过来了。不过，同步和异步并不是那么泾渭分明，还有一种半同步模式，它的做法是将其中一个副本设置为同步的，其余的为异步，这样至少有两个节点（主节点和这个节点）拥有最新的副本。增加新节点快照文件+修改日志的方式节点失效如果从节点失效，恢复后可以比对日志，追赶主节点。如果主节点失效，需要选出一个新的主节点，这个过程称为切换。切换涉及的步骤：探活：一般基于超时的心跳机制。选举新的主节点。配置系统使新主节点生效。典型问题，比如脑裂，是说有两个节点都认为自己是主节点的情况。超时时间如何设置，长的话，恢复时间比较长，短的话，会造成不 ...继续阅读 (53)

本章对比了JSON、Thrift、Protocol Buffer、Avro几种编码方式在模式演进时如何保持兼容性，更好的支持程序滚动升级。随后列举了几种进程间数据交互的方式，这些交互方式利用之前介绍的数据编码方案保持服务的兼容性。向后兼容：较新的代码可以读取较旧的代码编写的数据，新代码兼容旧数据向前兼容：旧代码兼容新数据一般而言，向后兼容比较容易，因为编写新代码时，清楚旧数据的格式。数据编码格式程序数据两种表示形式：内存中的数据结构。为了写入文件或网络传输的字节序列。前者转为后者称为编码（也称序列化），后者转为前者称为解码（也称反序列化）。语言特定的格式JSON和XML{ "userName": "Martin", "favoriteNumber": 1337, "interests": ["daydreaming", "hacking"]}文本形式，易读性强，开发调试友好，数字编码有模糊之处，缺少模式，占用空间大。Thrift和Protocol BufferThrift有两种编码格式，为BinaryProtocol和CompactProtocol。Protocol Buffer常被称为pb，只有一种编码方式，和Thrift的CompactProtocol非常类似。由于Thrift和Protocol Buffer二者非常类似，因此下面只介绍pb ...继续阅读 (56)

本章主要讲了数据库存储涉及到的核心数据结构，以及数据库两种主要的应用场景：OLTP和OLAP。核心数据结构在最基本的层面，数据库只需做两件事：向它插入数据时，它保存数据；之后查询时，它返回数据数据存储两种形式：追加和原地修改。索引是为了提高查询速度的额外数据结构。哈希索引典型产品：Bitcask。内存侧：hashmap索引，key为查询的键，value为文件中数据偏移量。磁盘侧：真正的数据文件存储在磁盘上。为什么进行日志分段？书中说为了避免用尽磁盘空间。我当时看了很纳闷，不分段，也就是一直往一个文件写，边写边检测文件大小是否小于磁盘剩余空间不就完了？为什么非得分段？请教了下chatgbt，给出了三个理由：磁盘碎片化：长时间持续写入一个文件会导致磁盘碎片化，即文件被分散存储在物理磁盘的不同位置。文件扩展：文件会持续增长，没有合适的管理，会耗尽磁盘空间（这不废话吗）。日志管理：分成一定大小的段文件可以更好的管理日志。当文件达到一定大小时，关闭它并将后续写入到新的段文件中，可以使得日志的查找、备份、传输等操作更加方便和高效。我又纳闷了，为什么长时间写入一个文件会碎片化，分段就不会？还有文件扩展，你边写边检测不就行了？chatgbt给出的解答：关于碎片化：持续写入一个文件时，磁盘上连续的可用空间可能不足以一次性写入整个文件，这倒是，文件越大，能够连续写入的概率越小。边写边检测的方法是可行的 ...继续阅读 (64)

本章主要讲了数据模型，以及围绕模型所构建的查询语言。数据模型关系模型由Edgar Codd与1977年提出，这种模型将数据组织成关系（relations），在SQL中称为表（table），其中每个关系都是元组（tuples）的无序集合，也就是SQL中的行。MySQL、Oracle、PostgreSQL等一众大家耳熟能详的数据库都属于此类。适用于：结构一致的数据。事务性要求比较高的情况，比如金融、银行等领域。文档模型所谓文档模型就是可以直接存储json、xml等非结构化数据，数据的关系和模式不再是首要关注的对象。相关的产品有Redis、MongoDB、HBase等等。NoSQL[1]：不仅仅是SQL最初作为一个标签出现在2009年的开源、分布式以及非关系数据库的见面会上。NoSQL的优势：扩展性更好，支持超大数据集或超高吞吐量。大部分是免费开源，成本优势。查询的局部性更好，也就是一次将所有数据都查出来了，不用做联结和子查询。更具动态和表达力的数据模型，和应用程序数据结构比较接近，减少了阻抗失谐[2]。树模型一个示例，下面是比尔盖茨个人简历的json描述：{ "user id": 251, "first_name": "Bill", "last_ name": "Gates", "summary": "Co-chair of the Bill & Me ...继续阅读 (70)

当前的许多系统都是数据密集型应用（data-intensive），已经不再受限于CPU，关键在于数据量、数据的复杂度以及数据的快速多变为特性。比如大型电商如淘宝、京东，新闻推送如腾讯、凤凰网，社交平台如twitter、facebook等等，都属于这一类型。基本构成组件：数据库高速缓存索引：根据关键字快速检索流式处理：比如一些flink任务，或者自定义的worker承接来自MQ的消息，进行相关的数据处理批处理：定时任务数据系统的三个方面：可靠性可扩展性可维护性可靠性可靠性大家天天挂到嘴边，用大白话说其实就是有点小风小浪，甚至中风中浪，系统是否稳定，书面一点，就是系统在遇到局部故障时，仍能维持服务的能力。比如一些典型的场景：参数输入错误流量突然增加了一倍分布式部署的某个机房突然挂掉了黑客入侵遇到这些情况，系统能不能很好的应对。故障（fault）和失效（failure）前者强调组件偏离规格，强调单体和局部，后者强调整体和全局，也就是说整个服务已经没法提供服务了。但事实上，大家在日常工作中区分不了那么精细，而且说法也不尽相同，书中提出这一概念，是为了说明100%可靠的系统是不存在的，系统的容错是有限度的，并不是所有的故障系统都能够容忍。故障应对措施：硬件故障：冗余备份，比如RAID、UPS电源。软件错误：难以预料，更加隐蔽，只能充分的测试，报警和可观测系统。可靠性很重要，但并不是绝对的。比 ...继续阅读 (68)

背景git命令有点多，选项就更多了，别说初学者无所适从，作为老鸟，如果长期使用ui界面操作，或者一段时间不用命令行也是晕头转向。我呢，就是常年使用idea的ui界面操作git，突然切换vscode，界面和操作方式和之前idea不太一样，用起来很不适应，只好重新把命令行学起来。命令行有一个好处，无论是vscode，还是idea，抑或是其他的什么ide，都可以“一招吃遍”。前提大部分企业通常仓库会有一个主分支master，大家基于主分支拉取自己的开发分支，修改代码，然后提交，最后合并到master分支。常规流程常规流程基本上就是：创建分支——>更新代码——>提交代码——>删除分支。创建分支# 查看本地分支git branch# 创建本地分支并切换git branch branch_name origin/mastergit checkout branch_name# 或者一步到位git checkout -b branch_name origin/master更新代码除非个人仓库可以使用git pull origin master，其他多人合作的代码库，我建议一律采用先fetch后rebase的方式更新代码。# 拉取最新代码git fetch origin master# 查看本地当前代码与远程主库区别，如果只想看commit，去掉-pgit log -p HEAD..origin/m ...继续阅读 (79)

hexo博客建了好久了，一直以来都有几个痛点：只能电脑发布。在手机日期流行的今天还挺要命的，有时候上一天班真心不想开电脑，电脑不能随时随地使用，比如地铁上。图片的插入不方便。需要找图床，或者保存在同名文件夹中，然后手动再插入markdown文档。换电脑需要重复配置hexo环境，每次都要安装一次nodejs以及一堆依赖，特别是后端程序员，使用nodejs不多，时间一长都忘了咋配置，每次都得百度一番。最近在twitter上受@lencx_启发，发现一套可以全平台多端发布hexo博文的方法，方案如下：使用github discussion作为数据源，天然支持分类和tag，还有天生的版本管理功能，如果注重隐私，还可以选择私密仓库。当发布或修改discussion时，使用github api将discussion同步下来，生成markdown文档。使用github action创建hexo部署环境，将markdown发布成博文。github有手机端，支持ios和android，支持上传图片，网页端也是相当的好用，github action透明发布，不用再关心部署环境。大家也可以举一反三，使用这种方式，同步发布公众号什么的。整体github action配置为name: deploy discussion to hexo blogon: # init workflow # push: # ...继续阅读 (64)

leetcode 235给定一个二叉搜索树, 找到该树中两个指定节点的最近公共祖先。leetcode 236给定一个二叉树, 找到该树中两个指定节点的最近公共祖先。这两个题二字之差，一个是二叉搜索树，另一个是二叉树，搜索树是有序的，二叉树是无序的。二叉搜索树还是比较好写的，我当时很快就写出来了。思路就是根据root与p和q的大小比较，递归的选择一边，直到root介于p和q之间。class Solution { public TreeNode lowestCommonAncestor(TreeNode root, TreeNode p, TreeNode q) { if (root == null) { return root; } // 因为是有序的，所以只需要查找一边 if (p.val < root.val && q.val < root.val) { return lowestCommonAncestor(root.left, p, q); } if (p.val > root.val && q.val > root.val) { return lowe ...继续阅读 (69)

一直以来，我都认为，一个人如果在某个领域造诣很高，他讲话应该是深入浅出的，要想深入浅出，少不了举例。一个人如果只会罗列概念，满嘴术语，说明他的水平其实还没到炉火垂青的地步。忘了是谁说的了，说是“最伟大的数学家能给邻居老奶奶讲述微积分”。本书就是这种旁征博引，深入浅出的类型，带着那个时代鲜明的语言特点，简单明了，单刀直入，怕你学不会，怕你不敢学，而不是像现在七绕八拐，怕你学会了，怕你读懂了，仿佛这样的话作者的水平就低了。或许有些例子现在大家觉得过时了，因为那些示例还带有明显的阶级叙事。是啊，好像一提阶级就是苦大仇深，振聋发聩，现在流行的是温情脉脉，男人至死是少年，女人四十小仙女……，资本给每个人都编织了美丽的梦，那梦美的人都不愿醒来。老话讲，忠言逆耳利于行，这个时代或许人们已经不习惯听真话了，也没人愿讲真话了，但是无论你想不想听，有没有人讲，真相就在那里，你不找它，它就来找你，因为梦终有醒来的一天。 ...继续阅读 (60)

螃蟹，对于我这个北方内陆人来说，一直都是一种神秘的食物。三次尝试，三次的不知所措。带上这次，我对螃蟹的印象依旧模糊，也许更多的是对其复杂性的敬畏。鲁迅说，第一个吃螃蟹的人必定是勇士，我深以为然。那个决定将这种多脚生物送入口中的人，一定拥有无与伦比的勇气和探索精神。想象一下，最初发现螃蟹时的人们是如何克服对这种奇异生物的恐惧，然后尝试并发现其可食用的。他们或许在艰难的试错中，一点点探索出螃蟹的美味所在。但对我来说，每一次螃蟹摆在眼前，都是一场挑战。它们外表坚硬，似乎隐藏着无数秘密，而我却只能束手无策地面对。第一次，我犹豫不决，不知从何下口；第二次，尝试摆弄着螯，却频频遭到无情的反击；第三次，更像是在和一位不熟悉的工艺品较劲，除了些微的肉，却没能品尝到更多。螃蟹在餐桌上的优雅摆放，似乎与其野性十足的外表形成了鲜明对比。从那盘螃蟹身上，我看到了别人娴熟地挥舞着锤子和钳子，轻松地剥开蟹壳，取出丰盛的肉。而我，则像是面对一门未解之谜，不知如何下手。或许，对于北方人来说，对螃蟹的陌生感正是一种美好。在每一次碰触中，我仿佛能够重新审视这个世界，发现那些隐藏在食物背后的文化与习俗。而尽管我对螃蟹的品尝历程充满了困惑与挣扎，但我却体会到了尊重和欣赏它所蕴含的独特之处。或许，尝试螃蟹并不只是一次简单的美食探索，更是一次对勇气和耐心的考验。第一个吃螃蟹的人是勇士，而我，也在每一次失败和困惑中，慢慢地成长 ...继续阅读 (65)

给定一个整数数组 nums，将数组中的元素向右轮转 k 个位置，其中 k 是非负数。示例 1:输入: nums = [1,2,3,4,5,6,7], k = 3输出: [5,6,7,1,2,3,4]解释:向右轮转 1 步: [7,1,2,3,4,5,6]向右轮转 2 步: [6,7,1,2,3,4,5]向右轮转 3 步: [5,6,7,1,2,3,4]示例 2:输入：nums = [-1,-100,3,99], k = 2输出：[3,99,-1,-100]解释:向右轮转 1 步: [99,-1,-100,3]向右轮转 2 步: [3,99,-1,-100]提示：1 <= nums.length <= 105-231 <= nums[i] <= 231 - 10 <= k <= 105题意挺好理解，就是将一个数组循环右移嘛。如果能够使用一个额外的数组，那将是非常容易，将数据拷贝一份，然后依次拷贝到偏移下标的地方，但是如果要求O(1)的空间复杂度呢？也是不难想起来，比如示例一，从下标0开始，依次将下标0的元素挪到下标3，即1挪到4的位置，以此类推，4挪到7的位置……，但是点子易得，方案难想，因为里面有许多细节需要确定。比如就这样挪动下去，截至条件是啥呢？一个很自然的想法是对挪动次数计数，截止条件就是计数值等于数组长度，我当时就是这么想得，可是这不是全部的真相。比如举个简单的例子，数组为 ...继续阅读 (68)

根据Javadoc的说法，A reentrant mutual exclusion Lock with the same basic behavior and semantics as the implicit monitor lock accessed using synchronized methods and statements, but with extended capabilities.ReentrantLock是一个类似synchronized的可重入互斥锁，拥有类似的行为和语义，以及一些扩展功能，比如公平锁、非阻塞尝试、可中断。早年间，有传言说ReentrantLock的性能不如synchronized，不过这一点Java的架构师Brian Goetz在《并发编程实战》中作了澄清：在Java 5.0中，当从单线程（无竞争）变化到多线程时，内置锁的性能急剧下降，而ReentrantLock的性能下降则更为平缓，因而它具有更好地可伸缩性。但在Java 6.0中，情况就完全不同了，内置锁的性能不会由于竞争而急剧下降，并且两者的可伸缩性也基本相当。可见，ReentrantLock在性能上一直都没有落后过，如果硬要说有，那也是领先。作者还告诫“像‘X比Y更快’这样的表述大多是短暂的”。回到正题，下面是ReentrantLock的一个典型用例。class X { ...继续阅读 (78)

给你单链表的头节点 head ，请你反转链表，并返回反转后的链表。示例 1：输入：head = [1,2,3,4,5]输出：[5,4,3,2,1]示例 2：输入：head = [1,2]输出：[2,1]示例 3：输入：head = []输出：[]提示：链表中节点的数目范围是 [0, 5000]-5000 <= Node.val <= 5000这道题经常被同事们戏称为“送分题”，比如你面试别人时特别想要那个人，那就给他出这个题。那意思是说这道题是个人就会，但是我见过不少人阴沟翻船的时候，原因可能是这道题太简单了，以至于刷题时都不屑于刷，到了面试这种高度紧张的场合，一着急写不出来了。所以大家不要掉以轻心，复杂总是起于简单，而且本题是解其他衍生题的基础，比如234. 回文链表，92. 反转链表 II。一开始看这道题时我的想法是，既然你是要把链表反转，那我依次将每个节点的next指针换个方向不就行了，示意图如下。代码如下。class Solution { public ListNode reverseList(ListNode head) { if (head == null) { return null; } ListNode cur = head; ListNod ...继续阅读 (63)

根据Java Doc的说法，Semaphore是一个控制访问某种资源并发量的组件。Semaphores are often used to restrict the number of threads than can access some (physical or logical) resource.例如，下面是一个使用信号量来控制对Item池访问的类：class Pool { private static final int MAX_AVAILABLE = 100; private final Semaphore available = new Semaphore(MAX_AVAILABLE, true); public Object getItem() throws InterruptedException { available.acquire(); return getNextAvailableItem(); } public void putItem(Object x) { if (markAsUnused(x)) { available.release(); } } // N ...继续阅读 (71)

给你一个单链表的头节点 head ，请你判断该链表是否为回文链表。如果是，返回 true ；否则，返回 false 。示例 1：输入：head = [1,2,2,1]输出：true示例 2：输入：head = [1,2]输出：false提示：链表中节点数目在范围[1, 105] 内0 <= Node.val <= 9我常觉得解链表题好比理耳机线，通常链表题都不会涉及太多的算法，要得是细心和耐心，一不小心就可能缠作一团，所以做链表题大家拿笔画一画，就比较清楚了。“回文”大家应该都知道啥意思，就是镜像，第一个和最后一个一样，第二个和倒数第二个一样……，以此类推。但是，链表没法像数组那样直接按索引随机读取，所以得把后半段反转一下，之后一个指针指向头，一个指针指向中间，依次往后检查。这一个题相融合了三个题：链表反转、寻找链表中点、判断回文。先写链表反转，没啥好说的。方法也有好多种，记住一种就行了，记的多了还容易乱，我比较习惯头插法，啥叫头插法，就是不断的将“头”的后一个节点移到头的前一个节点，直到最后一个节点，就完成了反转，如下。private ListNode reverse(ListNode head) { ListNode dummy = new ListNode(-1, head); ListNode cur = head; while (cur.nex ...继续阅读 (70)

之前时不时的看网上有人在玩树莓派，可以折腾不少有意思的小项目。说树莓派就是一个大号的单片机，哎，一说单片机我可就不困了，想起上学那会和小伙伴们逛电子元件市场，买来51单片机、电阻、电容、面包板……，在宿舍拿着烙铁焊接，烧录程序，联调测试……。唉！好久没折腾这些玩意了，你别说，手还真的有点痒。为了“忆苦思甜”，同时也为了满足自己的折腾欲，上周终于下定决心买了一个，几番对比后，最终选择的是4B 4G版本。经过一个周末的折腾，电子宠物终于养起来了。目前折腾的进度:烧录系统配置wifi配置默认用户密码解锁root用户修改软件源配置BT下载配置网盘客户端配置samba配置minidlna安装kodi家庭影院挂载硬盘设置静态IP下面细说过程和遇到的坑。烧录系统烧录挺顺利的。从官网下载系统，链接为https://www.raspberrypi.com/software/operating-systems/，我选择的是Raspberry Pi OS with desktop and recommended software 32位版本。之所以选择这个版本是因为软件比较全，在折腾的过程中不至于陷入不停安装软件或依赖的地狱，毕竟第一次折腾。没有下载64位系统是因为看网上评论说64位系统刚出，性能和稳定性还不如32位。下载完成后，使用SDFormatter格式化SD卡，使用Win32DiskImager ...继续阅读 (67)

以数组 intervals 表示若干个区间的集合，其中单个区间为 intervals[i] = [starti, endi] 。请你合并所有重叠的区间，并返回 一个不重叠的区间数组，该数组需恰好覆盖输入中的所有区间 。示例 1：输入：intervals = [[1,3],[2,6],[8,10],[15,18]]输出：[[1,6],[8,10],[15,18]]解释：区间 [1,3] 和 [2,6] 重叠, 将它们合并为 [1,6].示例 2：输入：intervals = [[1,4],[4,5]]输出：[[1,5]]解释：区间 [1,4] 和 [4,5] 可被视为重叠区间。提示：1 <= intervals.length <= 104intervals[i].length == 20 <= starti <= endi <= 104首先我们来看，题目要求一组区间合并后的结果，如何合并取决于两个区间的关系。那两个集合的关系共有几种呢？共四种关系：包含、被包含、有交集、无交集。具体到编码上，如何判断是哪种关系是通过判断区间的上下边界。比如你想判断[1, 3]和[2, 6]的关系，首先是否是包含关系，你得判断2和6是不是都大于等于1小于等于3，发现不是，再判断是否被包含关系，即1和3是否都大于等于2小于等于6，也不是，接着再判断是否有交集，发现是交集的。有交集的就要合并，合并后变为[1 ...继续阅读 (72)

之前写过一篇关于AQS的源码分析的文章，介绍了AQS是Java并发组件的基础，基础的介绍了，我们再看看它的应用，因此从这一篇开始我将依次介绍下AQS在Java各个并发组件如何应用的，先从CountDownLatch开始。CountDownLatch，有时也叫闭锁，它的作用就像一个大门，初始是关着的，线程在“门外”等候通过，在某一时刻大门打开，线程一起通过，大门打开后一直会保持打开状态，不会再关闭。它用在什么场景呢？一个典型的场景是JVM的warmup，我们都知道JVM刚启动时，由于JIT还没介入，系统的响应是比较慢的，需要发送一些请求让JVM快速“热”起来，即所谓的warmup。这个过程需要确保warmup的请求处理完，才能去接线上的正常请求，这个场景就可以用CountDownLatch来实现。也就是CountDownLatch源码中抽象出的代码示例，class Driver { // ... void main() throws InterruptedException { CountDownLatch startSignal = new CountDownLatch(1); CountDownLatch doneSignal = new CountDownLatch(N); for (int i = 0; i < N; ++i) ...继续阅读 (68)