我个人的理解：
- 云对应的是本地。比如云集群，指的是使用云端资源搭建的一个服务器集群。这个集群可以搭建在 k8s 上，也可以是一群 VPS 裸金属
- 云原生，指的是是否能利用 k8s 的环境特性。例如通过 k8s 完成自动的重启、扩缩容、升级等等运维操作

可以考虑 GreptimeDB ，和常见的日志存储在官网都有对比文章。写了一大堆 v2 不让我发，麻了
利益相关

不是什么专业人士，但是也算持续爱好骑行了一段时间br />1. 90 % 以上都是绿道，路况好，可以考虑直接上公路（没必要 gravel ；考虑骑行体验可以给公路车换更宽的胎或者真空胎）。3k 的价位我没记错 vook 大概差不多，也可以 B 站看看推荐
2. 建议去线下店试试尺码和骑行姿势，或者提前了解一下。几何最好可以偏向舒适。另外如果准备长期骑车的话可以看下骑行裤或者带坐垫的裤子
3. 下雨不建议骑，对车对安全都不好
4. 30KM 不算远，一个半小时到两个小时强度也 OK ；到公司能洗澡的话更好了。晚上不是下班晚注意力不集中就没问题
5. 但是可能要看下怎么停放。夹的脚撑不是很推荐；条件可行的话可以买个停车架放

我遇到过一个非常 niche 的场景。在地图 app 中，需要导航的情况下，普通尺寸的手机屏幕会不太好展示周边的路况、路线和商店的情况；地图缩小能看到更大范围的路况路线，但是商店也被进一步隐藏了。

这个时候我想也许折叠大屏会有点用；折叠大屏应该都是这种针对性很强的场景能发挥普通手机发挥不了的作用

折叠小屏感觉目标是替换日常手机用法，但是价格和折痕可能需要进一步权衡。一直处于一个有兴趣试一试但是兴趣不是很大的情况（

@vcmt 七八年能攒下 100 个，就算是省吃俭用也是厉害的。但是客观的说，这条件在北京你要说人中龙凤，我觉得也不至于。拿几个大厂来说，五六年努努力税前总包能到百万的也不算少见
相比之下男方工作三年攒下 50-60 ，单论薪资可能还是男方高点。当然男主说了现在被大厂裁了去一个小厂摸，但是大概率 IT 行业的起薪还是 OK 的

再从另一个角度看，假如女方找一个差不多收入的男的，就算也能省吃俭用攒下一百来万，全加起来这两百万能在北京买什么条件的房？
原帖男方也说了，提出选项之一就是分了，女方不同意。（我猜大概率在这女生选项里面男主的条件已经算得上靠前了，再考虑上女生这个时候的年龄和其他条件

不过 anyway ，我觉得我原先的观点是成立的。

@vcmt 原帖里有说，本科毕业工作大概七八年，还长他一岁（

这个 AI 省流漏掉了一个很重要的信息。原文提到男方一线城市，但是后续的聊天记录里面提到了亦庄。那么这个一线城市就是北京。
请注意，北京可不是普通的一线城市（

北京土著家庭，男方工作三年能攒五六十个，你说男方图女方一百万我觉得有点侮辱京爷了（

北京（大概率是全款）房（可能还要看地段和大小，但是再怎么样也比亦庄一百万首付只要的房子好太多了）。这房子哪怕是租单间也许一年都要十几万（


女方这么理直气壮怎么不直接分了了事（
原帖 OP 自己在下面提了，自身外貌也不错，自己也不怕重新开始（

纯文本编辑器还是 sublime ，全（ desktop ）平台都有，免费而且**启动**够快。只用来记录一些快速的东西，直接关闭重启 buffer 也还在

说存 ELK 的能问下数据规模和成本吗（

我的 PC 里面有三块不同的 SSD ，一块装 windows ，一块装 Linux 。默认从 Linux 盘启动，需要进 Windows 就从 boot item 里面选
折腾过不少 arch-based 发行版，endeavourOS 是唯一一个能自动识别 Windows boot item 的

一般所有的表默认要求有 `create_time` 和 `update_time`（ ns 级别的精度），然后分页如果没有其他的要求就可以 `order by create_time`

在这个基础上用分页就没什么大问题

The one and the only HHKB(studio)

soc 倒是无所谓，但是尺寸太大了，没办法用
nothing 一直没出过小尺寸的手机，如果能有的话还是挺有想换的（来自 xperia 遗老（ bushi

iPad mini ，从六代开始就买了，今年出了七代第一时间以旧换新
睡之前在床上刷点视频看看网页，以前都是用手机，屏幕小操作麻烦看着不爽。自从用了 iPad mini 好非常多，基本上在家再也没有用手机作为娱乐用途过。尺寸刚好在一只手到两只手之间，再大的尺寸也没办法和手机一样随心用了
除了出门只能带手机，在家坐着用台式，iPad mini 应该是个人消费电子里面使用最多的数码产品了

> 如果你加入了一家新公司，当前业务需要引入分布式事务，你会选择哪种方案？

先考虑能不能用最终一致性处理，多系统的异常能不能用回滚解决。实在不行再考虑实时分布式事务。
如果一家公司之前没有相关积累和经验，贸然上所谓的“分布式事务”的方案，大概率后面要踩不少坑

一台 PC 台式机，两个盘分别装 Windows 和 Linux ，默认启动盘是 Linux （当 server 用，GUI 都没有），设定每天早上 9 点自动开机
办公室 MBP ，家里一台 Mac Mini M4 作为开发前端。浏览器文本编辑文档之类的在 macOS 下，开发就 vscode Remote SSH 到 Linux 机器上
到家需要切 Windows 就关机重启一下就好了

@irisdev 当然是手打的，这哪有 ai 那味儿（ xs

现代数据库并不是一个精确的概念，只是我自己想的一个词，用来代指理念上设计更现代的的数据库，比如内置的 region 的设计？
现代数据库也不等同于分布式，根据适用场景现代数据库也有单点（大部分现代分布式数据库都可以同时单点部署和分布式部署）和“嵌入式”数据库（比如有名的 duckdb ）

1. 较早的数据库，例如 MySQL 这种对外提供的表概念就是最小化的逻辑单位的情况。通过特定的第三方中间件去实现分库分表，例如在数据库集群上包装入口，或者使用特定的数据库驱动库去链接数据库。本质上是通过特定的逻辑实现自动分库分表

以查询用户的订单为例。设定所有用户的 UID 前两位或者前三位均匀分布在 00-99 或者 000-999 ，然后针对用户的订单（或者任意的用户数据）的操作必须带上用户 UID 信息。中间件拦截这个 UID 字段，并且自动解析，路由到对应的分库分表

虽然使用上是几乎无感的，但是作为研发要知道实际下面可能数据路由到了不同的库表（甚至可能会路由到不同的物理数据库集群中）。这点在事务中要尤其注意

2. 现代的数据库（？）在底下存储的时候，除了有表的概念，有些会进一步细分 region ，或者叫数据块的逻辑单位。数据实际存储在 region 中，表只是 region 的逻辑集合，region 通过主键自动或者手动进行划分，对数据进行分割存储

相比于分库分表这样的作法理论上可以保持单表的无限扩容，并且可以保证数据在同一个数据库的逻辑概念中（不至于要分库）

悲观锁，也就是 select for update ，一般同时满足两种情况
1. 有一个大的事务（也就是不仅操作这一条记录，会涉及起码两条以上的数据库记录），并且需要保持这些操作都原子，或者全成功或者全失败
2. 在整个事务周期中这个记录不能被其他请求修改
理论上来说涉及到钱的一律全部悲观锁（基本上也满足以上两个场景）

乐观锁的目的更多在于保持单条记录的原子性，比如操作记录对应的版本号，允许重试，但是版本更替的记录不能丢失。例如失败了可以通过重拾消息来保证最终更新成功，之类的