体验海淘-Google Nexus 7

一直想买个安卓 Pad 玩玩,正好 Google 家出了 Nexus 7,很眼馋。但遍览淘宝代购,发现 8G 版最便宜的还要 1670,排队者甚众。仔细算了一下,觉得代购有点儿黑。本来价格比算上关税、运费都要贵,还不是现货,需要预付款排队,不定得等多少天。于是就抱着体验的想法,直接海淘了一把。

海淘肯定得看攻略,Nexus 7 的攻略虽然不多,但也足够了。其实难选的无非是两点:一是在哪里买,除了 Google Play,还有其它网上商店,各有优劣;二是用哪个转运公司,这个也是各有优劣,都得看前人的经验。

我比较懒,转运公司选择了用的比较多的 CUL 中美速递。注册以后会给两个转运地址:一个 CA 加州的,一个 DE 特拉华州的。地址中有个人识别码,在网站下单后送到该地址的商品会被记录到个人的名下,并转运回国内。

我想买 8G 版,只能选择 Google Play 商店并且交 13.99$ 的运费。由于 Google Play 限制销售地域,我就挂了个美国的 SOCKS 代理,在 Google Wallet 顺利用一张 Visa 信用卡配合 CUL DE 的地址下单,没有被砍单。下面就简单用时间记录一下海淘过程,都转换为北京时间:

2012-07-25 21:19:Google Play 下单成功,Gmail 信箱收到订单收据;
2012-07-26 13:23:Gmail 信箱收到发货通知,拿到 UPS 追踪号码,于是去 CUL 页面填写货物预报。
2012-07-26 14:25:填写货物预报时发现收货地址写错(街道地址填成了加州的 914 Ajax Ave),在 Google Play 提交请求修改 UPS 包裹收货地址街道部分;
2012-07-27 02:17:UPS 显示包裹离开 Louisville, KY;
2012-07-27 05:56:收到客服响应,同意修改 UPS 包裹收货地址,但要求提交完整的地址,并说明只能尽力帮忙修改;
2012-07-27 08:03:提交完整地址给 Google 客服;
2012-07-27 08:14:Google 客服帮忙完成了 UPS 包裹收货地址的修改,UPS 追踪显示地址已修改;
2012-07-27 23:05:UPS 显示包裹已完成配送;
2012-07-28 09:00:登陆 CUL 发现包裹已入库,重2磅,于是提交订单,给了5元小费,支付宝付款,然后订单状态就一直显示为处理中;
2012-07-31 09:00:登陆 CUL 发现总算发货了,订单中能找到 EMS 追踪号。但我傻了吧唧地去 EMS 网站上查了两天,都没有查到追踪信息;
2012-08-02 21:00:总算发现早期那个追踪号应该在 UCS 网站上查,查了一下,是7月30日 10:26 发货的,看来包裹在 CUL 仓库里呆了两天。
2012-08-06 11:09:接到快递电话,Nexus 7 到手。

由于中间回了趟家,也没有预计到转运到国内速度会那么快,于是2日到6日之间一直没有关注包裹的追踪情况。到手之后查了一下 EMS 网站,才发现转运的速度还不算慢(EMS的时间貌似都是本地时间):

2012-07-29 22:26:00 UC 纽约 到达处理中心
2012-07-30 21:00:00 UC 纽约 离开处理中心,发往中国 上海
2012-08-04 07:32:00 上海邮政速递物流大宗邮件收寄处 收寄
2012-08-04 10:51:09 上海邮政速递物流大宗邮件收寄处 到达处理中心,来自上海邮政速递物流大宗邮件收寄处
2012-08-04 11:30:00 上海邮政速递物流大宗邮件收寄处 离开处理中心,发往上海市邮政公司邮政速递局
2012-08-04 14:04:11 上海邮政速递物流大宗邮件收寄处 离开处理中心,发往国内出口
2012-08-04 16:34:00 上海市 到达处理中心,来自上海邮政速递物流大宗邮件收寄处
2012-08-04 16:58:00 上海市 离开处理中心,发往北京市
2012-08-05 09:27:41 北京市 到达处理中心,来自上海市
2012-08-05 12:58:42 北京市 离开处理中心,发往北京邮政速递上地分公司上地营运部
2012-08-05 15:10:50 北京邮政速递上地分公司上地营运部 到达处理中心,来自北京市
2012-08-05 15:54:48 北京邮政速递上地分公司上地营运部 安排投递
2012-08-05 16:14:00 北京邮政速递上地分公司上地营运部 未妥投
2012-08-06 07:26:37 北京邮政速递上地分公司上地营运部 安排投递
2012-08-06 11:37:00 北京邮政速递上地分公司上地营运部 投递并签收

最后总结一下几点经验:

  • 全部时间:11天14小时
  • 全部费用:199$(8G版)+13.99$(美国国内运费)+ 75¥(CUL转运费) + 5¥(CUL小费),整体算下来比淘宝代购便宜 200+
  • 信用卡:工商银行信用卡网银支持开通/关闭境外无卡支付功能,支付前开通,扣款完关闭,海淘比较安全
  • CUL 服务:比较差,包裹入库、发出没有邮件通知,只能人肉登陆去看;QQ 客服常年离线;微博官方账号无响应。但从整个转运结果来看,也还算靠谱。更新:最近很多人抱怨CUL不靠谱,所以我这里也不建议大家用了。
  • CUL 羊毛:邀请用户注册,下单付款后,邀请人和被邀请人都能获得 20 积分,以后下单能抵 20 元运费。我的 CUL ID 是 solrex,也可以直接点击这个邀请链接注册,你懂的!

淘宝OceanBase架构笔记

OceanBase架构图
OceanBase架构图(引自 rdc.taobao.com)

OceanBase 是淘宝研发的一套分布式 NoSQL 数据库系统。具体它是什么、怎样实现的,可以参考李震老师(花名楚材)的《OceanBase介绍》和杨传辉老师(花名日照)的《Oceanbase – 千亿级海量数据库》。这里我只是谈一下自己的感想,如有谬误,敬请指正。

OceanBase 相较于其它分布式存储系统,有一个特性是支持跨行跨表事务。这个特性太明星了,让几乎所有其它系统黯然失色。但实现这个是有代价和局限的,OceanBase 只能使用单机接受更新,也就是说它的 UpdateServer 只能有一个(或者准确地说,一组)。由于 UpdateServer 失去了扩展性,OceanBase 的应用必须建立在单机能够满足增量更新和查询性能需求(查询可以通过从机部分缓解)的前提下(或者硬件性能的增长快于性能需求的发展)。为满足这一点,需要对软件和硬件都进行很好的优化,幸运的是从淘宝核心系统团队成员的文章来看淘宝应该不缺这样的专家,也不缺买设备的钱。值得一提的是,每个公司看来都有自己的基因,看到 OceanBase 我脑子里就浮现出淘宝数据库架构中单机 Oracle 挂一堆 MySQL 的景象,何其相似啊!

阳振坤老师(花名正祥)在《淘宝海量数据库之二:一致性选择》这篇文章中说 OceanBase 是支持强一致性的。如果 UpdateServer 没有从库的话, 能够很容易理解。但考虑到 UpdateServer 从库也提供读服务,且 UpdateServer 之间使用 binlog 进行同步,那么还能否保证强一致性这一点我比较怀疑。也许会有其它的辅助机制来保证这一点,例如在 MergeServer 上做一定的策略。

在高可用性方面,对 RootServer 的说明较少,不清楚 OceanBase 有没有实现 UpdateServer 宕机后的 Master 选举。由于使用 binlog 同步,可能宕机恢复方面还是有一些风险的。

将 MergeServer 和 ChunkServer 部署在一起是个很好的选择,这样查询时能够利用一定的局部性。但除非根据业务需求非常精妙地部署,否则不可避免需要请求其它 ChunkServer 上的数据。我不知道它的查询是 MergeServer->(UpdateServer, ChunkServer0, ChunkServer1...),还是 MergeServer->(UpdateServer, MergeServer0, MergeServer1)。不同的模式有同的优缺点,如果 ChunkServer 只做存储的话,查询的过滤、合并应该是在 MergeServer 上做的。如果选用第一种方式请求,ChunkServer 间传输的数据没有过滤和合并,数据量较大;如果选用第二种方式请求,UpdateServer 的压力可能会被放大,视 MergeServer 封装的功能而定。

OceanBase 的介绍中没有提到 Chunk 或者 ChunkServer 是否分主从,也没有提到整体更新机制。考虑到更新是以批量方式合并到 Chunk 中,也许为了简化,Chunk 或者 ChunkServer 只是互备,没有主从。为了保证 ChunkServer 合并 UpdateServer 上冻结/转储数据时查询的正确性,可能用两阶段提交,不过我想仍然是一个很复杂的过程。

早上起来就想到这里,以后有问题再补充吧。

PS: 之前将楚材错当成了阳振坤老师的花名,已更正之。