"For 27 years, Sun has stood for courage, innovation, a willingness to blaze trails, to envision and engineer the future."
Good luck, Sun!
April 2009 Archives
可怕，很可怕。
其实也没啥，年度对帐单其实就是把月度对帐单里面的帐目做了一下summary，然后分门别类地把刷卡的明细排列出来，告诉你每个月花了多少钱，有多少调整金额和charge（我从来不相信国内某银行宣传材料上写的那种月底不把钱还清是好的理财策略的说法，无论如何不还清导致最终的还款现值pv都会比还清的高，所以这项几乎一定是 < 0的）。
不过我比较好奇的是这么大量的数据是如何存储和查询的。难不成是事先查询好保存成一个待下载的数据吗？想想看，这么大用户量跟数据量（当然，热数据很少，而且访问模式其实和邮件比较类似），还是需要动些脑筋才能做好的，也许这也是当天交易只减信用额度而不反映到实时帐单上的原因。
和蛇头GG讨论了一个关于卖票的问题，简单地说是票很有限，需求量很大，如何能够尽可能高效地让票以尽可能公平的方式卖出去。
我设计了一个分布式的结构来解决这个问题，当然这个原型可以进一步改进，此处按下不表。记录一下我对这个结构公平性的描述的一个比喻：
"因为其他人也hash了，或者换句话说，这个系统其实不介意一开始有人就注定拿不到票。 就跟一大群人排队抽签是一样的道理，其实这个就相当于说一帮人排队抽签决定去拿一个信封， 然后拿到空信封的可以重新排队抽签，要么拿到票。"
这个系统其实要求参与进来的客户机一起参与计算（但是这些计算并不会明显加大服务器系统的负载），有一些能想到的缺陷，也许需要克服，也许根本不是问题？先把想法记下来再说。
今天又帮人做了一次恢复，上次干这个事是十几年前的事情了。数据恢复是个手艺活，恢复个60%-70%基本上靠工具，剩下的就靠运气和经验了。
想起很久以前做的一个小工具。简单地说是先把磁盘复制一份出来，然后在数据文件上去操作，把已知的链接上，然后把未知的文件的首簇、长度算出来，在空闲区里面找（很明显，大文件恢复的成功与否很大程度上取决于你多久整理一次磁盘以及是否经常删除文件）然后接个链出来。我当时很感激某文本编辑软件每次都会把之前的文件改名做BAK然后把文件整个重新写一遍。
我对做数据恢复这事是很反感的，总体而言。21世纪需要的是健壮的、支持事务和版本的文件系统。
