xanpeng 最近的时间轴更新
xanpeng

xanpeng

V2EX 第 8872 号会员,加入于 2011-05-21 22:27:38 +08:00
xanpeng 最近回复了
@void1900

开发的底裤是不是要谨慎? —— 存储研发底线(底裤)就是不能丢数据。我们都知道和理解代码会有 bug,存储研发这里要谨慎地通过各种手段去容错。
存储一般也就是 raid,这里没人拿单机硬盘洗了 —— 我并非特指此文,可能本站其他文章里提及。
固件问题,我自己都碰过,镁光的 ssd,算靠谱吧?时间门,5000 小时候会导致系统死机 —— 固件问题遇到过的人不少,所以需要前面说的谨慎和容错
准入问题,bug 能遇见就不叫 bug 了,这里不是说有 bug 才对,而是 bug 不可避免,程序员应该理性面对 —— 这又是个概率问题了,是可能有 bug 的,不过出现几率小,真出现了,就认了,但同时也得反思准入流程是否有漏洞。而且真是大规模固件 bug,好事啊,这锅可以正大光明地甩出去了呀
@void1900 “我想说的其实是身为开发者要理性面对数据丢失问题” 附言里这句我认同。
不过现实是诸多中小企业难以都做到关键数据本地备份。
@reus 有可能是单点落盘,然后异步跟上。但可能性比较小,应该不会有人这么做,否则异步窗口期故障概率大很多,绝达不到 9 个 9.

另外关于备份,要求用户备份不大现实,这么多中小企业,让他们自己去做备份不大现实。一般买卖双方都相信那个 9 个 9.
反而云厂商自己做备份更好吧。不过主动做备份的云厂商有么,我也不清楚...

我也好奇,出过数据问题的国内外云厂商们,多少故障是落在那 9 个 9 之外的?我印象里还没有人这么承认过吧。
而且硬盘静默数据错误这个说法,十有八九是背锅的,真正错误原因没说出来。因为:
1、如果同批次硬盘固件有问题,丢数据的客户很可能不只这一家了。
2、如果真是硬盘固件问题,怎么准入的? tx 肯定用大厂硬盘的吧(不然就是自己作死,相关人得负责任了),大厂硬盘大规模出现类似问题的,没怎么听过吧。这次真是问题的话,这个锅妥妥地甩给硬盘厂商了吧。

真正原因应该是副本间一致性没做好。
另外拿硬盘静默数据错误来挡枪,也是不专业的。
tx 这样的大厂,静默数据错误怎么着也得解决了吧。阿里肯定是宣称解决的,tx 我印象里也这么宣称过,但不确定。
这个问题没什么好洗的,做存储的都知道,底裤是不能丢数据。
你可以数据离线一段时间不能访问,就是不能丢数据。
是说 9 个 9 的可靠性,理论上的确不是 100%,但...没必要拿这个理论极值来洗了吧。

至于其他的,那是其他问题(比如赔偿方式额度等,比如备份等),可以把讨论重点放到其他问题上,但逃脱不了这个事实:你丢数据了。

也没必要拿备份来洗。
客户本地备份了,是客户自己做的好。掩盖不了你云存储丢数据的事实。
客户没有备份,他们自己可以怪自己没备份,但你 tx 就不能怪他没备份了。毕竟他相信你云存储宣称的 9 个 9,毕竟他本地可能就没有数据中心。

拿单机硬盘来类比的就更可笑了,这么来洗的,要么是真不理解,要么就是故意了。本来云存储多副本就是要解决单机硬盘可靠性问题的。
2015-07-24 16:35:25 +08:00
回复了 ksupertu 创建的主题 云计算 京东的 git 代码托管平台是挂了还是彻底关闭了?
不怕JD“偷窥”你的代码么?
专业:计算机
工作:存储
2015-07-20 17:54:43 +08:00
回复了 saxon 创建的主题 Python py 与 C Py 与 C++的混写
2015-04-27 00:07:29 +08:00
回复了 Livid 创建的主题 Dev 2015.4.26 关于服务器搬回国内第一周时候的卡顿问题(已解决)
我2个月前才接触到rq,当初要找一个python work queue,然后找到的看起来简单的、可用的就这个,然后我还一直以为它就是一个玩具,没想到真有实际使用啊。
另外感觉用起来始终有些不爽,感觉原来偏工具,于是照着改写了,改成偏lib...结果是可控度好很多,自己用起来顺手很多。
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2882 人在线   最高记录 6543   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 13ms · UTC 11:24 · PVG 19:24 · LAX 04:24 · JFK 07:24
Developed with CodeLauncher
♥ Do have faith in what you're doing.