@wysnylc 你才抬杠好么
你什么系统做到单节点 100 纳秒多次调用？一般操作系统调度时间都要几十微秒。就算针对低延迟特别调优，你随便处理处理数据 100 纳秒就过去了。你要每秒 1 千万次插入操作才会碰撞。先问问你数据库性能到这个数没有？
就算到了，后面还有 14 位序号，正确使用的话，重复需要超过 10 亿次插入每秒。你用的什么数据库可以做到这个性能？
有这功夫和我杠，为什么不去查一下 UUID 的生成方式，再自己用笔算一下？


@passerbytiny UUID1 是靠生成机制*保证*不可能重复
UUID4 才是拼概率。然而 128 位随机，实际上碰撞概率也是低到忽略不计。
UUID3/5 是靠 hash 算法的碰撞复杂度来拼概率

@wysnylc 正确使用 UUID1 是不会有碰撞的。要碰撞需要你在 100 纳秒内反复生成还刚好遇上随机数碰撞
UUID4 是纯随机，鉴于值域有 128bit，你可以算算 10 年内碰撞到一次需要多高的频率。实际上也基本可以忽略，当然，比不上 UUID1 的绝对保证。优点是不依赖，不暴露机器信息
其他 UUID 各有生成逻辑，使用之前彻底搞懂生成逻辑，然后论证为什么可以避免碰撞即可。

@passerbytiny 和储存无关，主键要进索引的。硬盘是不值钱，但是 1.内存值钱 2.CPU cache 值钱 3.硬盘 IO 操作数量 /延迟值钱
能不能用？能
但是数据量上来以后性能会很差

最后，主键只是数据库内在的储存结构的一部分。如果你用的是单机或者客户端了解的分表分库，那自增主键的性能反而更好
楼上说什么方便给用户的，你自己想想看，数据库主键直接暴露给用户，这是求人碰撞攻击你吗？给用户看到的 token 为什么不和内部 ID 解耦？ token 和 id 解耦之后还能 revoke
就算用自增主键，也可以另外生成一个带索引的 token 字段，隐藏用户 ID 和主键用什么，没有半毛钱关系

再吐槽一下 varchar 做主键，存的是 UUID。真的不知道在想什么。任何读过数据库的用户手册的人都想不出这样的主意。你就没有想过为什么某些数据库要专门做个 UUID 类么？

UUID 用什么 varchar ？
首先 UUID 是定长的，不需要变长类型。定长类型在储存和索引时有优势
其次 UUID 是 hex，一共才 36 种字母数字，为什么作为 text 存？任何 UUID 完全可以导出为二进制
数据库提供 UUID 数据类型时存 UUID 类型。原因是比较顺序。UUID1 前几位是机器代号，最后才是随机数。所以最好从后往前建立索引，这样可以帮助索引自然平衡。

UUID 最适合分库的情况，UUID 的随机性保证了分库的平均。同时结合机器代号可以保证不同机器无需单点也能保证不碰撞。

raid 卡直接挂了不用怕，很好处理
用 SAS multipath 的话甚至可以做到 hba 挂了阵列都还在线
怕的是 raid 卡发神经写脏数据……
所以服务器务必上 ECC 内存，包括 nas

炒股不投资，投资不炒股

@dxgfalcongbit 技术上真没那么复杂。无源 tb 线结构还是很简单的，但是长度和带宽受限。
有源线贵很多，但是其实一般无源线也够用了

@YueZhang “临时有事，不想事假扣钱”
这不就结了
你不走正规流程，为了不想扣钱。领导批是情分，不批是本分。你可以查查员工守则，看看年假相关的规定。
另外，你领导这样做，就是已经对你不满了，但懒得怼你而已。如果直接拒绝了请假，理由是临时请假未交接的话，你就可以考虑跑路了。

和领导相处没有那么难。他想要什么，你想要什么，以这两样为前提考虑，就不难理解。遇到不讲理的避开些就是。

严格来说，年假是需要提前请好的，而且需要交接工作。我请年假都是提前两个月就和老板说明大致日期和长度。提前一个月左右发邮件确定日期，往日历上挂提醒。为的就是给老板充分的时间能安排工作。oncall 也要全部找人代替。

事假才是临时请的。然后我们公司没有单独的事假。病假不查证明。年假，事假，病假实际上都是混用的。如果我有事，一般就请半天，实际上不计考勤，因为本来就是弹性工作制。但是这都是以老板同意为前提。

反正只要老板同意，什么都可以……
一周五天全部 wfh 都可以……
年假休超额变成负数也可以……
早上起不来说自己头痛请病假也可以……

所以和老板关系要搞好一点

我年初连休 17 天，用了 11 天年假。
组里还有个 senior，去年 11 月说，我年假要过期了。12 月整个月都是年假。

@pangleon 你说的是哪家外企？年假不提前安排还有理了？员工守则上怎么规定的就应该怎么做。老板从来不看，这是情分。问清原因要求交接，这是本分。

新代码应该测试，从测试分支到主分支，还有一层层测试，这个阶段出问题，就不可能 merge。也不存在什么责任。
线上出问题，别纠结谁的锅，大家一起先应急处置完，这是对用户负责。能力范围内能处理就先处理，处理不了就赶紧找人，上级还有同事，反正只要有关的先叫起来再说。
等情况稳定了，收集好日志和记录，再讨论 root cause。背不背锅是整个组的事，轮不到你。虽然代码是你写的，但其他人批准了 PR，那就也有责任。领导管理不足，那就也有责任。
其他组代码会影响到你组的，那就需要相互 code review，相互负责。出了事，事批准过的，那大家都有责任。没批准过的，首先你活该，其次你领导还是有责任。

@devlnt 你英文有没有问题大家看的懂
*extrapolated*
*statistical models*

一比一的实验是不可能的，否则希捷不用卖了

@ysc85 你到底是千兆网还是万兆网？
千兆网，假设 MTU 1500，TCP 效率 94.93%，所以理论最大 TCP 数据带宽 118.6MB/s
不排除 samba 带压缩，那就可以解释超过这个数的速度

@devlnt Based on the observed error rate over a few weeks or months, the MTBF is estimated and not representative of how long your individual drive, or any individual product, is likely to last. Nor is the MTBF a warranty
建议你好好补习一下英文呢。免得贴个链接打自己脸。

@devlnt AFR and MTBF are population statistics that are not relevant to individual units.
墨菲定律此处适用，average ≠ maximum

建议换个标题。raid50 牛爆天际，raid6 吃饱了撑的。
你爱用就用，问个 P

@devlnt 你也知道工信部油耗做不到啊？那怎么 mtbf 就一定能做到？那你应该往高了估还是往低了估？
一万块一起测？一万块测一小时就等于一万小时的数据？硬盘到寿命末期故障率会迅速上升。混用批次，分批投用，就是为了避免一批一起挂的情况。
你还没考虑人为错误和重建前的人员响应时间。你能做到 24 小时机房有人，长备替换盘么？如果用热备的话你会希望热备随时上线还是错开负载高峰再上线？

*更可能是厂家根据各个原件的故障率，理论推算全盘故障率*

@devlnt 你怎么证明？这只是一个理想条件下的推算，实际上怎样，厂家也不可能知道。难道新出一块盘就先跑个十年再卖吗？最多高温加速实验，但是加速实验的前提就是假设了加速比例，实际上加速了多少，谁也不知道。很可能是厂家根据各个原价的故障率，理论推算全盘故障率。计算方法不同，得出的数据可以差好几个数量级。

要看实际数据，backblaze 有。真正生产线上跑出来的统计。