Everything you care about in one place
Follow feeds: blogs, news, RSS and more. An effortless way to read and digest content of your choice.
Get Feederraychase.net
四火的唠叨
Get the latest updates from 四火的唠叨 directly as they happen.
Follow now 84 followers
Latest posts
Last updated 3 months ago
关于近期求职的近况和思考
3 months ago
自去年秋天裸辞之后，一直在考虑职业生涯的问题。之后加入求职大军，目前进展还算顺利，作为软件工程师的下一站也将很快确定下来。但是这一次的 career break，虽说时间不算长，却给了我莫大的启发，我也有了一些思考。 从 fullstack engineer 到 platform engineer 其实在年初的时候就简要叙述过这个事情。熟悉我的朋友都知道，我的职业生涯有点奇怪，从 Huawei 开始，我是一个全栈工程师（fullstack...
聊一聊分布式系统中的时间
7 months ago
今天聊一下时间的话题。在分布式系统中，“时间” 是一个挺有趣，但是很难处理的东西。我把自己的理解简单整理下来。 不可靠的物理时钟 首先，单一节点的物理时钟是不可靠的。 物理时钟本身就有偏差，可是除此之外，可以引起节点物理时钟不准确的原因太多了，比如 clock jump。考虑到 NTP 协议，它基于 UDP 通信，可以从权威的时钟源获取信息，进行自动的时间同步，???就可能会发生 clock...
本地部署 Minikube + Docker 记录
7 months ago
我有 Mac 和 Windows，这些年折腾软件方面的环境 Linux 用得比较多，最近想安装一个 Kubernetes 的本地环境，本着 “生命不息，折腾不止” 的精神，打算在 Windows 上动手。了解到可以尝试...
几个有意思的分布式系统设计模式
8 months ago
分布式系统有它特有的设计模式，无论意识到还是没有意识到，我们都会接触很多，网上这方面的材料不少，比如 《Catalog of Patterns of Distributed Systems》，还有 《Cloud Design Patterns》等等。这里通过记录一些典型系统的方式，简单谈谈几个我接触过的，也觉得比较有意思的模式。 LSM Tree...
谈谈分布式锁
8 months ago
不要使用分布式锁 就像 Martin Fowler 说的那样，“分布式调用的第一原则就是不要分布式”，谈分布式锁也要先说，不要使用分布式锁。原因很简单，分布式系统是软件系统中复杂的一种形式，而分布式锁是分布式系统中复杂的一种形式，没有必要的复杂性就不要引入。 有的逻辑是没有副作用的（纯函数代码），那就可以无锁执行；有的数据经过合理的 sharding 之后，可以使用单线程（单节点）执行，那就单线程执行。 比如一种常见的模式就是使用 queue（比如 Kafka），任务全部放到队列中，然后根据 sharding...
我裸辞了
8 months ago
我裸辞了。 工作差不多十六年了，从来没有以离职后休假的方式休息过。今年还是比较特别的，我做了很多新的尝试，想改变一下自己，包括这最近发生的一件事情。事情发生得很快，我辞职了，在作为 engineer 加入 Doordash 一年零十个月后。 记录一下。 原因 我不是在二十岁的年纪，做决定容易缺乏思考，其实，我已经想了这件事情好久了。在这期间，我也和不同的朋友和同事讨论过，他们有的还在 Doordash，而有的也已经离开了。说起来，大致有三个原因： 第一个，是兴趣的不匹配。 郭德纲说过，如果你每天做的事情是你喜欢做的，那就是老天爷赏饭吃。这样的情况只在少数人身上发生，而我大致就是这样的少数人——不能说每天如此，但是在我职业生涯八成以上的时间，我工作做的事情，恰恰就是我喜欢做的。不过，今年我从一个做平台的...
入职后一些零散的感受和思考
over 2 years ago
有些时候自己会有一些想法，但是过于零散，想把它们记录下来，可是又找不到一个清晰脉络可以把它们串起来。入职已经两周了，我还记得快要五年前加入 Oracle 的时候，我也写了一篇类似零散的文字，不过那个时候是在入职一个月左右的时候。 Facebook 的唏嘘 我记得在五年前谈 offer 的时候，Facebook（现在改名叫 Meta 了）也给了 offer，他们的 recruiter...
近况更新：第三次换工作
over 2 years ago
最近发生了太多的事情，也没有更新 blog，来冒个泡。 我基本上是一个很长时间才会换一次工作的人，说好听点就是爱惜羽毛（工作经历），注重长期积累而非短期回报，说难听点那叫懒得动弹。 记得在 2012 年初的时候，我在人生中第一次换工作，从华为跳到亚马逊，那时候我已经在华为干了三年半了，其中的主要动机一个是想开阔眼界，另一个是可以不那么辛苦。 接着就是 2018 年初，在亚马逊干了六年之后，第二次换工作，从亚马逊跳到甲骨文，主要动机有两个，一个是我想在职业生涯有个突破，去参与云计算的浪潮；第二个是我觉得当时我的薪水已经严重偏离市场能给我的待遇了，所以想去谋取一份更合理的薪水。 这一次，在甲骨文干了 4 年...
常见分布式应用系统设计图解（十五）：支付系统
over 2 years ago
支付（Payment）系统可以很复杂，比如可以和银行打交道，和信用卡系统打交道。如果我们考虑用户在一家电商买东西，在结账的时候，借助电商支持的支付系统（Payment Service Provider）来完成支付行为。 支付系统需要结合商家（包含卖家和买家）一起来看。最典型的一种需求是，卖家在电商网站挂了东西卖，买家挑选了货物，结账并支付，电商依赖于支付系统来完成支付，并通知买家支付成功。 图中用两条虚线分隔出了 3 列，最左边是用户，中间是电商系统（比如 Amazon），右边是 Payment Service Provider（PSP，比如 PayPal）。支付操作需要保证幂等性，从而在重试的过程中保证不会被重复扣钱。有的电商自己会存储用户具体的支付信息，比如信用卡信息和银行账号信息，但是这样的数据管理成本由于安全需求的原因非常高，因此也有很多电商省掉这个麻烦，选择让...
常见分布式基础设施系统设计图解（八）：分布式键值存储系统
over 2 years ago
Key-value 存储系统大概是分布式存储系统中最常见的一种类型了。从功能需求的角度说，最核心的包括： 可以创建一张表和删除一张表，同时对于表的数据可以进行：读，即 get(key) 返回 value写，即 put(key, value) 当然，也有一些其它的功能需求，比如支持事务性，支持 key 排序查询，range key...
常见分布式应用系统设计图解（十四）：日志系统
over 2 years ago
典型的互联网应用的日志系统，从功能需求上看主要包括收集，存储和分析，以及展示这样三个部分，因此整个系统我觉得也可以按此思路大致可以分为三个部分： 日志收集，从宿主机上采集业务应用的日志，发送给远端的日志系统；日志存储、分析和后期处理；日志查询和分析数据展示。 非功能需求方面，我觉得可以考虑这样几个要点： Durability：这是最重要的，尽可能不要丢失日志，到服务端的日志不要丢，在客户端的日志，也是如此，即便服务端不可用或连接断开，客户端的日志也要保存在本地。Availability：其次是可用性，要保证高可用。Performance：相较来说，日志系统的 performance 主要是吞吐量而非延迟，和一般系统比较起来说，网络带宽需要特别算一下。Scalability：业务应用增减引起的 scale 变动会非常频繁。 图中虚线为控制或辅助的逻辑，实线为实际的日志数据，或处理过的日志数据的流向。客户端日志需要分片，日志的客户端采集和处理策略存储在客户端，可以通过配置文件修改，或者通过一个第三方的系统统一将数据同步过去。本地的分片日志经过部署在客户端宿主机上的 Log Collector 应用来收集，这个应用需要独立进程，尽量避免影响主营业务。日志实时地发给...
再谈谈互联网外企在中国的失败
almost 3 years ago
最近亚马逊将要关闭 Kindle 中国区业务的新闻唤起了我的感慨，这则新闻在朋友圈刷屏了。这件事情作为触媒，让我联想到很多东西，我就想，要不然理一理思路，写一点东西吧。 这件事情，基本上就是说，亚马逊宣布将于一年之后即 2023 年 6 月 30 日，在中国停止 Kindle 电子书店的运营，被媒体称作...