Posts

Redis 持久化机制: RDB 和 AOF Redis 持久化 为什么需要持久化? Redis 是基于内存的数据库, 服务一旦宕机, 内存中的数据将全部丢失. 通常来说可以通过数据库来恢复这些数据, 但这会给数据库带来非常大的读压力, 并且这个过程会非常缓慢, 并导致程序响应慢, 因此 Redis 提供了把内存数据持久化到硬盘, 并通过备份文件来恢复数据的功能, 即持久化机制. 持久化的方式 目前 Redis Documentation 上对持久化的支持有以下几种方案: RDB (Redis Database): 将某个时间点上的数据生成快照 (snapshot) 并保存到硬盘上 AOF (Append Only File): 将每个接收到的写操作记录到硬盘上, 这些操作可以在 Redis 重启时被重放, 并用于重新构建 Redis 数据库 RDB + AOF: AOF 和 RDB 的混合模式 RDB RDB 指对整个数据集在特定时间点生成快照 (point-to-time snapshot), 可用于Redis的数据备份, 转移和恢复. 它是 Redis 默认使用的持久化方案. 工作原理 RDB 利用操作系统提供的写时复制 (Copy-on-Write) 机制来进行持久化, 即当主进程 P fork 出子进程时 Q 时, Q 和 P 共享同一块内存空间, 当 P 准备对某块内存进行写操作时, P 会将这块内存页进行复制, 并在新的副本上对数据进行修改, 而 Q 仍然读取原先的内存页. 这样既能够保证 Redis 实例继续服务外部流量, 又能够以最小的成本完成数据的持久化. 但正因如此, 持久化过程中的写操作是不会被记录的. ...

Disaster Recovery Architecture on AWS [TOC] The downtime of software systems could have a significant impact on business, customer satisfaction, reputation, or income of the company. Thus maintaining the availability and durability must be the most crucial part of a software system. Disaster recovery (DR) helps engineers prepare for disaster events. This post summaries the architecture for DR on AWS. DR objectives There are two key objectives: Recovery time objective (RTO): The maximum time range between service collapse and service restoration. It represents how quickly the service could be restarted. ...

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 的一段想法： ...