CodeSky 代码之空

阅读前提示：豆包手机本身的表现属于意料之中，也没有网上吹得那么神，也没有黑稿说的这么差。本身豆包手机的定位比起「手机」，更像是「玩具」。大家实际购买前可供参考。

当然我已经自闭一整天：3000 块钱买啥不好了。

硬件

配置

又拖更了很久！最近要打的游戏有点多……

在一个多月以前开始倒霉的我加入了我们的性能排查专项，主要解决我们平台站点网络反应慢的问题。（再不更新就要忘光了）。

为了以防各位难以理解文章的脑回路，首先先来简单描述一下我们遇到的场景：

1. 内部平台，因此没有办法使用全球 CDN 像 C 端那样加速
2. 全球化 team，使用者遍布全球各地
3. 数据合规，因此在美国数据只能在美国，欧洲数据只能在欧洲

也因此处理内部网络问题更加困难，如果说在 C 端可以用「部分用户网络问题」来搪塞的话，内部系统一个老板 Case 就要一查到底了。

还是流水账更新的快啊。

上一篇文章 博客重建计划中我们提到了整个博客基本上都是 Cursor 负责研发，而我负责需求和验收工作。本质上是一种研发模式的变更，包括 Terminal 从 iTerm2 转而用 Warp 一样，新一代的革命随着 AI 的发展逐步升级。

有意思的是，在我日常唠嗑的过程中，往往一些大厂的员工对于工具升级反而没有创业公司的员工接受度高，这里当然指的不止是互联网头部的几家大厂以及一些对于热点敏感的同学（没有开地图炮的意思保命警告）。

这主要是因为对于大厂来说，合规永远是一个顾虑，用别人的模型，别人的 API，如果数据泄露了怎么办，要自研，又只有头部那几家能有这个财力和人力去做，而且投入时间长，效果也没有那么好，也因此对于普通大厂开发的开发体验升级其实反而是滞后的（因为我已经问了不止一家创业公司直接报销 Cursor 了（抹泪）

还是流水账比较好写，先把流水账写了吧。

今年过年期间也没有什么年度规划，不过自 1 月开始进行了博客整体重写的计划，起因是因为之前从腾讯云迁移到阿里云时可能是因为 PHP 版本控制的不对或者是别的问题，导致博客没办法正常的上传文件到又拍云。

现在都是靠着脚本上传文件然后 copy 发布的，Obsidian + Typecho 的脚本也不是很好用，也遇到了 5xx 的问题，但是我已经不会写 PHP 了，更不要说 debug 了。

拖稿时间太长，只能努力还原……QvQ，因为如你所见的近期主要功夫都在重写博客系统和简历页面上了，当然也包括在 NAS 上部署的 gitea + action 的配置之类的，因此后面可以更新的文章还是挺多的

之前我也写过两篇 AI 相关的文章，不过因为不涉及到开发，只涉及到使用，所以我还是用 Windows 宿主机开发的，这次由于涉及到了开发，所以就得折腾一下 WSL GPU 加速的方案。

安装

Redis 是我们常见的缓存解决方案，但是使用不当的 Redis 同样会造成系统瓶颈。

慢日志分析

要启用慢日志分析，首先先要对慢查询记录进行设置：

1# 命令执行耗时超过 5 毫秒，记录慢日志 
2CONFIG SET slowlog-log-slower-than 5000 
3# 只保留最近 500 条慢日志
4CONFIG SET slowlog-max-len 500
5

实在不知道该编什么名字，总之先复习一下缓存吧。本文讲的重点是服务端缓存，尤其是 Redis 相关的设计。

概述

众所周知的是，我们的业务数据多数都会选择存储在 DB 里，但数据库本身是一个吞吐量有限的单点，在实际的高并发场景下，我们肯定不可能让所有的流量都流向 DB，因此在这种情况下，业务往往会涉及一些缓存来缓解 DB 的压力。

具体的来说，从客户端到服务端，链路的每一个节点都能具有缓存的能力。比如客户端的 HTTP Cache、边缘节点的 CDN 缓存，再到服务端缓存，包括内存缓存、Redis 缓存等等，在开头我们说过，重点是服务端缓存，因此我们会对客户端缓存暂且不表。（反正一言以蔽之也就是强缓存和协商缓存）。

我们经常会被问到这样一个问题：在一个下单流程中，如何保证数据的一致性。

如果我们在单服务单库中运行，那么很简单，使用数据库的事务就可以了。

但是正常来说，现在的所有服务都会采用微服务的架构，也就是说一个下单流程中，「订单服务」到「库存锁定」到「生成账单」到「支付交易」到「回调变更状态」，这几步将会有多个服务来共同完成。

此时我们必然不能让用户的任何一步失败，又或者必须保证失败后回滚一定成功，否则用户钱扣了，交易却没成功；或者造成了超卖，这些都会造成严重客诉。

为此才会引入分布式事务这个概念，也就是保障多个事务之间的一致性，要么全部成功，要么全部失败。

今天这篇文章主要是因为组内有 AI 分享，因此被迫营业了一回，本人平时并不怎么研究 AI，因此本文依旧是从使用和介绍的角度的个人锐评，并没有涉及原理知识，望周知。

开篇介绍

之前我们介绍过「AI 老婆」，如何让你的老婆来模拟唱歌，今天介绍的是应用面更广的「翻译」。（下次再抽到分享我可就没活了）

目前相信大家也一直在用 AI 翻译来读文章、看教程、看 Youtube，并且或许你会觉得它还挺好用，翻译是不是要失业了——本文就将通过一些工具的实际使用效果和预期来判断「翻译是否会失业」。

总算在 618 换了新电脑，写篇文章简单纪念下。 本文（基本）不涉及代码，望周知。

在写上一篇稿子的时候，甚至早在之前写那篇 AI 相关稿子的时候，就发现我的 2017 年的台式机和 2019 intel core 的 Mac 可以说是相当不给力，第一没法指望 GPU 加速、第二实在是卡的不行，风扇呼呼转，愣是连写个稿子都卡（主要是需要开大量的 Chrome Tab 查阅资料，这年头的网站真是一个比一个狠），三是公司的电脑是 M2 Pro，可以说是相当流畅，以至于我整天非常气氛于自己当初一万多买的 Mac 和八千买的台式机怎么就那么卡。

痛定思痛，公司的电脑也有限限制，还是得有一个自己的新电脑！