如果 SSD 做 raid 一般是为了高性能，用 raid5/6 的话校验会成为瓶颈。所以 SSD 一般用 raid10 或直接 raid0 用作缓存

@mxT52CRuqR6o5 那就不是 RAID 了啊
RAID 是什么的缩写？ Redundant Array of Inexpensive Disks
Inexpensive 才是重点。你用好的，贵的盘，那就违背了 RAID 的设计理念了。
你可以叫它 RAED：Redundant Array of Expensive Disks

@NightTeam #26
我更倾向于认为是你的实现的性能太低，是时间戳而不是随机数保证了不重复

snowflakes 设计时就指出了依赖时间戳保证唯一性的问题：如果在小于时间戳精度的时间内快速反复生成 ID，就有可能发生碰撞。机器 ID 就是为了规避这个情况。因为单机下维护一致性容易多了。
你倒好，把机器 ID 去掉了。在大规模使用时几乎可以保证会发生碰撞。

@NightTeam #10
"Snowflake 的碰撞问题是因为中位用了时间戳，薄雾算法没有用时间戳，所以不会收到单位时间的限制，也不会产生碰撞问题。另外不用担心高流量下的唯一性，Jmeter 5000w 数据测试过了。"
要保证没有碰撞只有维护某个状态或者维护某种单调递增性。你测试没遇到不代表它不可能发生。
你没有遇到碰撞不排除是占了伪随机数算法的便宜。
我就问你两个独立生成的随机数可不可能有碰撞？这是一个数学问题。

@oneisall8955 喷的是标题党和自大。每个算法都有其适用范围。他这个算法和 snowflakes 解决的完全不是一个问题，去比较性能有什么意义呢？而且，还实现错了。

今天没开车
那轮胎昨晚已经漏气漏空了啊，明天打气打不起来的。汽车轮胎没有内胎，全靠压力压在轮毂上。新轮胎要快速充气压上去
就算能打起来，严重亏气状态下长时间放置，胎壁已经严重变形。补好了也没用了

发现漏气就要尽快去最近的修车店补胎。

@7DLNU56W raid6 不也就是 raid5 多了一点点容错？ raid 本来就是这样的技术
raid6 软件 raid 不贵，而且只要 CPU 不差，性能都很不错
支持 raid5/6 同时性能好的硬件 raid 都很贵。不贵的都是凑合实现的，性能好不了

raid5 的重建成功率可以计算的，网上有各种计算器。你可以查查你用的盘的 Datasheet，找到相关参数带入计算即可。实际情况肯定比理论计算更复杂。硬盘实际可靠性取决于使用环境，所以一般取 Datasheet 数值再减一两个数量级。同时阵列的可靠性还取决于你有没有及时更换硬盘，以及硬盘是否不同品牌不同批次

建议你了解一下叠瓦技术。简单来说，叠瓦盘写入一个磁道会影响隔壁磁道。所以必须先读出隔壁磁道再一起写入两个磁道。硬盘厂有各种优化，但还是会有坑的。

算法方面我是外行，但是正经学过一点分布式
如果说错了请见谅

算法民科
1.维护分布式全局递增数，同时满足高性能和高可用，非常困难
2. snow flakes 的最后一部分递增就是为了利用单机内部实现原子递增的性能够高。同时保证唯一性。你用 16 位随机数替换，碰撞问题怎么解决？我很怀疑你的算法在高流量的情况下还能保证唯一性
3. 你还注释用真随机就更搞笑了。真随机必须每一个 bit 都来自熵。/dev/random 才是真随机 /dev/urandom 只是含有部分熵的伪随机数。一台没有用户输入的服务器，除非使用硬件熵源，可用的熵非常有限。也就是说真随机几乎无法实现高性能
4. 获取时间戳不一定就很费性能，配合 CPU 内部计数器时间可以做到高性能。
5. 因为 1，你最后选择了单机。你想避免 Redis 单点，结果你自己又成了单点。你有没有实际测试过靠 Redis 维护单调递增，同时由本地服务 /库来计算 ID 的情况？

“由于不是纯数字组成，这就无法满足趋势递增和单调递增这两个属性”
？？？？？
看得出这是 16 进制吗？ 16 进制可不可以转换为 2 进制？
uuid1 包含了机器 id 和时间，可以做到每个机器生成的 uuid 单调递增。还有其他算法。
uuid1 的缺点是操作系统的时间精度太低。所以无法保证在大请求量的情况下还能单调递增
这才是 snow flakes 等算法的起源

**如果你有 6 盘 raid10，那它用盘比 5 盘 raid6 多一块，可用容量一样

@594duck raid10 的优点是性能而不是安全性。如果你有 4 盘，那 raid6 比 raid10 更安全，因为 raid6 可以容许任意 2 盘，而 raid10 有 1/3 的概率损毁。
如果你有 6 盘，raid10 不仅用盘多一块，安全性还比不上 raid6 。因为随机挂两块的情况下，raid10 依然有 1/5 的概率损毁。
但 raid10 不计算 parity，所以非常适合高随机写入的 SSD 阵列。因为随机写入意味着每个写入都要重新计算 parity 。如果只写 1byte，raid10 会影响 2 个盘，raid6 会写 3 个盘以及读剩下的所有盘。


@7DLNU56W
@goldenalex
群晖大部分是软件阵列。很多甚至没有 hba 。软阵列指的是单盘暴露给主机，CPU 管理阵列的写入。硬阵列指的是单盘隐藏（或者只可以通过特定维护 API 访问，不走工作负载） CPU 不参与阵列的写入与维护。操作系统只能看到虚拟单盘。
群晖虽然不需要外部主机管理，但它自己也是有 CPU 的，数据是在 CPU 是完成阵列操作的。
硬 raid 基本只有 raid 卡一种（少数情况是 USB 硬盘柜支持硬 raid ）
核心区分是操作系统能看到和管理单盘。

@libook 3 是 by design 。因为 raid 的设计目标是可用性而不是数据安全。raid 虽然有 parity 但并不要求校验。而且 raid5 的情况下如果校验失败也只能报错，因为发现 1bit 的错误需要额外 1bit，纠正需要额外 2bit 。实际上一般读的时候跳过 parity 。这也是为什么 raid5 的性能比 raid4 要好。
zfs 有校验，scrub 可以检测并（在有额外冗余度时）修复冷错误。

不至于那么慢，但也快不到哪去。你说的例子可能是 CPU 或者内存不够。那别说重建了，正常读写都费劲。

就算是 2TB 单盘，100MB/s 读写，那也要 5.5 小时才能重建完成
4T 单盘翻倍，8T 单盘又翻倍，就是 22 小时了
你所有硬盘要满负荷工作 22 小时，坏一块的可能性太大了
更恶劣的是硬盘都有 ure，一般盘的 ure 也就 10^-15 。这么多数据，还没有任何冗余度，重建过程中有错误数据很正常

用不用 raid5 取决于你对数据损坏的容忍度以及单盘大小。所以组 raid 单盘太大不是好事。单盘太小主要是性能问题。

zfs 会稍微好一点。首先 zfs 有校验，遇到 ure 能查出来，你可以死个明白。
其次 zfs，和大多数软 raid 和各种高级硬件 raid 一样，可以只重建已用的部分。但是 zfs 因为是文件系统自带，可以更细致一点。

Chromebook 不能硬解 VP9
据说 YouTube 如果发现是 Chromebook 就会给 h264，如果是其他电脑就给 VP9
mac 的话可以试试强制 YouTube 使用 h264 的各类插件

看到了你的附言，看来你还是没有明白问题的根源
你以为那里有个果实，其实那里早就没有了。人家只是指出了这一事实而已。是你自己的疏忽大意让果实没了，而不是那个指出的人。
没人劝你大度，大家都在一边倒地说你傻逼而已。
平台公开漏洞存在而不公开漏洞细节，这就完全没问题。你的客户跑了是你自己的问题。如果你能尽快修复并公开漏洞细节，给你的客户看到问题不大而且你行动迅速，这都是可以理解的。
如果平台完全不公布会怎样？客户系统上线了，出事了，后来查出来平台早就知道，平台负得起这个责任吗？
只要漏洞在那里，它就有可能会出事，而不是有人公布了才会出事。

还是请楼主公布一下公司哪家。做生意不讲诚信的公司不能合作。

你这可能是播放器不支持或者解码器没装好
用 MPC-HC 播放器试试

你又想稳定，又想要赚钱，这很难办啊。因为只赚不亏的买卖都在刑法上。

你首先需要一个明确的投资目标，这笔钱是多少年后要用。如果是十年以上，那在此之前市值就算下跌 50%又怎样？在目标日期之前涨回来不就好了？

@ihciah 大错特错
raid 卡的 bbu 是给 raid 卡的 ram cache 通电用的。不会任何其他元件供电。nas 不需要 bbu
bbu 是企业环境下提高随机写入 iops 用的

@cyang 那是个取巧的办法而已。但是如果有 UPS 连接的话还可以指定剩下多少电量才关机

你想想数据贵还是 UPS 贵？
UPS 首先功率要够，然后时间要够。其他问题不大，是不是正弦波也无所谓。反正 psu 里都要整流的
最好买能通知主机的，一般是 USB 口。否则断电了还不关机就没有意义了

你以为只有公布的那个人发现了漏洞吗？
他不告诉别人，就是没人知道？
一般来说，在安全领域，如果有白帽发现了漏洞，基本可以认为已经有黑帽在此之前已经发现并有可能利用这个漏洞。因为黑帽有真金白银的利益诱惑。

麻烦公司名字发一下，今后我们发现有什么漏洞保证不告诉任何人