Posts

Git Reference HEAD 用法 HEAD 最后一次 commit HEAD^ 倒数第二次 commit HEAD^^ 倒数第三次 commit，以此类推 HEAD~0 最后一次 commit HEAD~1 倒数第二次 commit HEAD^2 倒数第三次 commit，以此类推 回到以前的某次 commit git reflog # Reference logs 记录了本地仓库每一次更新分支的操作 git reset HEAD@{index} # 回到某一次提交，把文件修改留在工作区 git reset hash --hard # 加上 --hard 可以忽略掉所有文件修改 在最后一次 commit 的基础上添加部分改动 git add . # 把改动添加到暂存区 git commit --amend # git commit --amend --no-edit # 加上 --no-edit 如果最后一次 commit 已经 push 到 remote，那么在再次 push 的时候需要加上 -f 在以前的某次 commit 的基础上添加部分改动 git log # 找到要修改的 commit 的前一次 git rebase -i hash # 将 HEAD 移到需要修改的 commit 上 (vim) R edit # 将首行的 pick 改成 edit，保存退出 # 修改文件 git add . git commit --amend # 追加改动到这次 commit 上 git rebase --continue # 恢复 HEAD 把未 commit 的修改移动到其他分支上 git reset HEAD~ --soft # 撤销最后一次 commit 操作，但是保留文件修改 git stash git checkout another-branch git stash pop git add . git commit -m "your message here" 把某一次 commit 添加到其他分支上 git log # 找到需要移动的 commit 的 hash git checkout another-branch git cherry-pick hash # 把对应的 commit 应用到当前的 branch 撤销某次 commit git log # 找到需要撤销的 commit 的 hash git revert hash # 撤销对应的改动并直接 commit 撤销某次 commit 的某个文件 git log # 找到需要撤销的 commit 的 hash git checkout hash -- path/to/file # 把修改之前的文件添加到工作区 git commit -m "your message here" 放弃治疗 git fetch origin git checkout master git reset --hard origin/master git clean -d --force # 删除工作区所有 untracked 的文件和目录 或者 ...

使用 Mac Mini M1 作为软路由让全家设备出国 [TOC] 本文介绍如何将功耗超低的 Mac Mini M1 改造为软路由，让局域网内连上 Wi-Fi 的所有家庭设备都可以免设置直接出国。 代理客户端 首先需要下载一个可以运行在 M1 上的代理客户端，推荐使用 Surge 或者 ClashX Pro，前者买断价格较贵（每个 Mac 设备 $49.99），后者免费，本文以后者为例。 配置 一般机场会提供 Clash 的订阅链接，如果没有可以自行搜索 ssr/v2ray 转 clash 的第三方订阅转换服务，生成 Clash 订阅链接。 有了订阅链接之后，点击顶部菜单栏的 Clash 图标 -> Config -> Remote config -> Manage 管理订阅。 点击 Add，在 Url 中输入订阅链接，Config Name 可以任意填。 除此之外还要勾选 Clash 图标里的 Set as system proxy 和 Enhanced Mode 两个选项，这样才能保证 Mac Mini M1 能够成为网关。 ...

工作两年总结 2019 年参加腾讯的暑期实习面试认识了现在的总监，那段时间退租了原有的公寓寄宿在同学家里，面试当天又刚参加完 GoogleCloudOnBoard 在回去的路上，整个面试的过程非常仓促，气喘吁吁地拿着手机跟面试官打了两小时微信语音，虽然后来计划有变并没有在假期回国实习，但也因此获得了之后校招被总监直接内推到现在项目组的机会。于是后来在经历了四轮技术面试之后，某天在图书馆突然接到总监的微信语音，接着又是 HR 的沟通电话，才在回国的几个月前确定了要来深圳的天美。 两年的时间里经历了很多工作和生活上的试错和反馈，在此尝试总结和反思。 impact 刚上班的时候，认为工作无非就是做好老板安排的事情，月底的时候老板为你在这个月完成工作所付出的时间支付等价的薪资。那么理所应当地，如果你每天花更多的时间在工作上，每天加班到晚上 10 点，周六周日不间断工作，为老板创造更多的收益，那么老板就会更乐意为你支付更高的薪资，这也是为什么国内会有那么多人乐此不疲地内卷的原因。 实际上有些人虽然每天从不加班到点就走，不仅能拿到高绩效和更多的奖金，还能创造出很大的 impact。用李开复的话来说，impact 就是世界有你和没有你之间的区别。举个例子，你女朋友很爱去图书馆自习室，需要每天晚上 9 点登录学校图书馆网站，预约第二天的自习室名额，如果你花几小时写个脚本放在服务器上每天定时自动抢名额，为她省下了每天那几分钟的时间和精力，那么（为她每天省下的时间和精力 * 天数）就是你写脚本这件事的 impact；同时你还可以顺带把脚本给你爱学习的朋友们用，那么这个数值还可以乘上使用的人数。套用李沐大神的定义，impact 等于（受益人数 * 人均时间 * 单位时间价值差），单位时间价值差取决于你对这件事完成的好坏，如果有人写了一个更易用，响应更快的新的脚本，你的朋友们都去用这个新脚本了，那么这个脚本开发者创造的单位时间价值差就比你高。无论是工作产出、技术分享、指导新人、为团队规划和确定方向，都可以套用这个公式，来评判自己创造的 impact，提高创造 impact 的能力比不断付出劳动时间更能带来持续性收益。 后台开发 后台开发无非两部分：增删改查和高并发架构，前者需要数据结构和算法的知识，后者需要系统设计的能力，包括缓存设计、云原生、异步存储、数据拆分之类的。而游戏后台相较于互联网还多出了有状态服务和延迟敏感两个特点，并且在系统设计方面也有很大的细分差异。 游戏后台习惯于先在内存上读写数据，再把有状态的内存数据持久化到 db，而不是每次都去操作 cache / db，这和现在的互联网后台架构的“业务逻辑和数据分离”的指导思想有很大的区别。 服务器上云依靠 service mesh 进行通信，sidecar 注入和劫持流量，拿到数据包之后还要考虑做零拷贝来降低单机延迟，经过这些步骤之后如果延迟是 100ms ，对互联网业务来说或许是可以接受的，但对手游来说已经几乎高到无法容忍了；除此之外把功能不同的模块拆分成微服务后，还会极大地增加不同模块间通信的网络开销。 游戏后台进行云上扩缩容还要考虑 k8s 资源调度的效率，有状态服务的迁移流程，迁移时要保证不可服务的时间和粒度尽量小。 不同的业务有各自的刚需和痛点，把这些互联网时代催生的技术应用到游戏业务上时也要结合其对产品的价值来进行相应的调整，而不是生搬硬套。 游戏行业 2021 年的未成年人保护法和版号停发让国内各家游戏公司都在推进所谓精品化和出海两个方案。 因为版号少了，游戏公司一方面要投入更多资源到长线运营，也就是氪金上来保证现金流，另一方面只能保守地复制成功经验（moba，卡牌，打枪）来抢存量市场保证新游戏不会没人玩。长此以往玩家逐渐审美疲劳，也就遏制了青少年玩家对于游戏的兴趣，有关部门也能逐步加大力度断绝国内游戏行业的前途，最后再将其连根拔起，从此没了教培和游戏，年轻人也就能专心谈恋爱，从而提高生育率，解决人口危机了。 至于出海，目前有资金和技术储备跟海外厂商直接竞争的国内游戏公司也就只有腾讯了，不过对有关部门来说，制裁一个公司可比监管整个行业简单多了。 技术和产品 游戏后台最重视 n 个 9 的高可用，最害怕上线之后出现 bug。这两年里印象最深的外网 bug 有两次，一次是入职半年做 crud 时，因为没有仔细阅读文件里的多个名称相近的接口导致调用了错误的一个；另一次是某个元旦凌晨上线的功能，因为错误地估计了某个途径获取的数据条目数量导致预留的数组长度不够，后者在当时登陆高峰的时间段内造成了短暂的不可用。这些当然都不是因为技术水平不够，但确实会对个人口碑造成实实在在的打击。以前刷题或者竞赛时如果遇到这种小问题，最严重的后果无非是 ac 率降低和 5 分钟的罚时，但一旦转换到工作上，由于对技术审查的不严谨则会非常严重的影响产品和整个团队。 员工和公司 刚上班时会把公司当作学校，把工位当作图书馆或者实验室，手头没工作并且又没其他私事的时候，包括工作日晚上和周末，就喜欢在工位上看书学习。长此以往会牺牲不少个人生活的时间，同时也会让同事和经理都认为你是一个非常卷的人，从而影响对你工作态度和结果的评价，所以只要跟工作无关的活动一律不应在公司进行。 员工与公司之间的劳资关系也会影响工作效率。在互联网企业里劳资关系无非是简单的雇佣或合作关系，但腾讯的很多部门，尤其是在司庆到春节的一段时间里，喜欢以“家人们”来互相称呼，听到的时候会让人非常反感，这并不是健康的劳资关系。 刚入职的时候毛星云大神坐在离我不到 10 米的地方，经常和客户端开发的同事们有说有笑，或是讨论技术。他出事之后办公室里的几百号人却像无事发生过一样，大都自顾自地重复着前一天的动作，不免让人感到残酷和凄凉。大二的时候要不是偶然间搜到浅墨在 CSDN 上的 DX 教程，可能我的计算机图形学也就挂了。引用 Youtuber Vincent Chan 的一段想法： ...

《深入理解 RPC 框架原理与实现》读书笔记 概念 RPC (Remote Procedure Call) 叫作远程过程调用，它是利用网络从远程计算机上请求服务：可以理解为把程序的一部分放到其他远程计算机上执行。通过网络通信将调用请求发送至远程计算机后，利用远程计算机的系统资源执行这部分程序，最终返回远程计算机上的执行结果。 将“远程过程调用”概念分解为“远程过程”和“过程调用”来理解更加直观： 远程过程：远程过程是相对于本地过程而言的，本地过程也可以认为是本地函数调用，发起调用的方法和被调用的方法都在同一个地址空间或者内存空间内。而远程过程是指把进程内的部分程序逻辑放到其他机器上，也就是现在常说的业务拆解，让每个服务仅对单个业务负责，让每个服务具备独立的可扩展性、可升级性，易维护。在每个机器上提供的服务被称为远程过程，这个概念使正确地构建分布式计算更加容易，为后续的服务化架构风格奠定了基础 过程调用：这个概念非常通俗易懂，它包含我们平时见到的方法调用、函数调用，并且用于程序的控制和数据的传输。而当“过程调用”遇到 “远程过程”时，意味着过程调用可以跨越机器、网络进行程序的控制和数据的传输 选型 RPC 选型的衡量角度 使用 RPC 框架无非三个选择 自研RPC框架，可以从投开始设计一款符合业务特征和场景的 RPC 框架，但是自研框架需要有足够的资金和人力支持 基于开源的 RPC框架进行改造，让改造后的 RPC 框架更加适合业务场景。这种做法相较于第一种做法，人力成本没有那么高。但是这种做法需要经常与开源社区保持同步更新，一旦不再和社区版本同步，也许到某一个版本后，公司内部改造的 RPC 框架再也不能合并社区最新版本的特性，这种现象最终会导致慢慢向第一种选择选择靠近 完全使用开源的 RPC框架，并且定期与社区版本进行同步。这种选择的好处在于要投人的人力威本最低，一些问题可以借助社区的力量进行解决。但是由于业务场景的不同直接将开源的 RPC 框架拿过来用，这种选择往往存在很多局限性。框架各部分的设计都是为了更加优雅地解决业务场景的问题，而不是反过来让业务场景去适应 RPC 框架。而且 RPC 框架有自己的定位及未来的规划，所以很多规模不是太小的公司都选择在 RPC 框架上做些许改造来适应自己的业务场景 Java 对 I/O 模型的封装 NIO Java NIO 中最核心的就是 selector， 每当连接事件、接收连接事件、读事件和写事件中的一种事件就绪时，相关的事件处理器就会执行对应的逻辑，这种基于事件驱动的模式叫作 Reactor 模式。Reactor模式的核心思想就是减少线程的等待。当遇到需要等待的 IO 操作时，先释放资源，而在 IO 操作完成时，再通过事件驱动的方式，继续接下来的处理，这样从整体上减少了资源的消耗。 以下是 Reactor模式的五种重要角色： Handle（在 Linux 下称为描述符）：它是资源在操作系统层面上的一种抽象，表示一种由操作系统提供的资源，比如前面提到的网络编程中的 socket 描达符或者文件描达符。该资源与事件绑定在一起，也可用于表示一个个事件，比如前面提到的客户端的连接事件、服务端的接收连接事件、写数据事件等 Synchronous Event Demultiplexer（同步事件分离器）：Handle 代表的事件会被班注册到同步事件分离器上，当事件就绪时，同步事件分离器会分发和处理这些事件。它的本质是一个系统调用，用于等待事件的发生。调用方在调用它的时候会被阻塞，一直到同步事件分离器上有时间就绪为止。在 Linux 中，同步事件分离器就是常用的 I/O 多路复用，比如 select, poll, epoll 等系统调用，用来等待一个或多个事件发生。在 Java NIO 领域中，同步事件分离器对应的组件就是 Selector，对应的阻塞方法就是 select 方法 Event Handler（事件处理器）：它由多个回调方法构成，这些回调方法就是对某个事件的逻辑反馈，事件处理器一般都是抽象接口。比如当 Channel 被注册到 Selector 时的回调方法、连接事件发生时的回调方法、写事件发生时的回调方法等都是事件处理器，我们可以实现这些回调方法来达到对某一个事件进行特定反馈的目的。在 Java NIO 中，并没有提供事件处理器的抽象供我们使用 Concrete Event Handler（具体的事件处理器)：它是事件处理器的实现。它本身实现了事件处理器所提供的各种回调方法，从而实现了特定的业务逻辑。比如针对连接事件需要打印一条日志，就可以在连接事件的回调方法里实现打印日志的逻辑 Initiation Dispatcher（初始分发器）：可以把它看作 Reactor， 它规定了事件的调度策略，并且用于管理事件处理器，提供了事件处理器的注册、删除等方法，事件处理器需要注册到 Initiation Dispatcher 上才能生效。它是整个事件处理器的核心，Initiation Dispatcher 会通过 Synchronous Event Demultiplexer来等待事件的发生。一旦事件发生，Initiation Dispatcher 首先会分离出每一个事件，然后找到相应的事件处理器，最后调用相关的回调方法处理这些事件 Reactor 的三种模型 单 Reactor 单线程模型 单 Reactor 单线程模型就是在设计中只会有一个 Reactor，并且无论与 IO 相关的读/写，还 是与 IO 无关的编/解码或计算，都在一个 Handler 线程上完成。 ...

2022 年初 | 后端开发两年经验社招面经 字节 一面 coding: 对于一个数组，仅用一次遍历，等概率地随机出一个元素（对于每一个元素，从全局看，他们被选择的概率都应该是 1/n） 对于第 i 个元素，它在第 i 轮被选中的概率是 1/i 往后，只要选择了新的元素，它就会被淘汰；以第 i+1 轮为例，它被淘汰的概率是 1/(i+1)，那么反过来它被留下的概率就是 1 - 1/(i+1) 最终每一个元素被选择的概率如下，第一个 1/i 代表它在第 i 次被选中，其他数代表它在后续的每一轮被留下 followup：等概率地随机出 k 个元素 对于第 i 个元素，它在第 i 轮被选中的概率是 k/i 往后，它唯一会被淘汰的场景是：选择了新的元素，同时从已有的选择中，等概率地选择到了它；以第 i+1 轮为例，它被淘汰的概率是 k/(i+1) * 1/k = 1/(i+1)，那么反过来它被留下的概率就是 1 - k/(i+1) * 1/k = 1 - 1/(i+1) 最终每一个元素被选择的概率如下，第一个 k/i 代表它在第 i 次被选中，其他数代表它在后续的每一轮被留下 coding: 实现 Fisher–Yates Suffle void shuffle(vector<int> v) { int n = v.size(); for (int i = n - 1; i >= 1; --i) { int j = rand() % (i + 1); swap(v[i], v[j]); } } 二面 system design：主播开播，如何把这个消息推送给他的千万级 follower 设计数据仓库（数据库也可以） 消息队列 followup：推送之后，主播已经下播，怎么处理 followup：怎么保证消息推送或被消费 followup：如何保证消息不重复 三面 DB 迁移流程 ...