分类 全说中国话 下的文章

【译】App Store Review Guidelines for iOS Apps

iOS应用商店审核指南


译者注:翻条款类的文档太尼玛折磨了。。。3000多字总算折腾完了,里边可能有一些不像人话的地方,请指出,我肯定虚心接受,择机改正。文档里可能有好多错别字,我会慢慢发现纠正的~~~祝大家开发快乐!

原文链接在这(需要IDP登陆):http://developer.apple.com/appstore/guidelines.html

简介

非常高兴您能付出宝贵的时间和精力来开发iOS应用。成千上万的开发者的经历表明,无论从专业技术还是经济收入上,开发iOS应用都是个不错的选择,我们将协助你你更快的成为其中一员。这篇App Store Review Guidlines主要是为了协助你弄清楚开发过程中会遇到的一些疑惑,加快你提交应用的审核过程。

我们认为应用不同于书籍和歌曲,我们不支持这些。如果你要讨论宗教信仰,那么应该去写书。如果你要谈论性,那么写书,或者去写歌,或者去做一个生理卫生的应用。看起来可能有点烦人,但我们仍然决定App Store不接受上述内容。记住下边这些原则,会对你有所帮助:

有很多小孩子会来商店下载应用,而且除非父母们设置了家长管理(事实很多人不设置),否则孩子们是不受任何限制的。所以我们要关注孩子们。

现在商店里有超过350,000个应用。我们不需要一个款差劲的应用。一款不能提供一些有用的功能,或者只是哗众取宠的恶作剧的应用,肯定通不过审核。

如果你的应用一看就是一个三两天拼凑出来的东西,或者你只是想把一个练手应用上到商店里,跟朋友秀一把,那在被拒以后一定要hold住。我们有大批严肃的开发者,不希望高质量应用与这些残次品为伍。

我们会拒掉那些,有越线内容或行为的应用。那么红线是什么呢?子曾经曰过:“等真见到的时候,我才知道”。还有,我们相信你越线的时候,你也会知道的。

我们提供一个审核版,如果你的应用被拒了,你可以在那上诉。不过你威胁我们,或者乱喷,肯定是于事无补的。

如果你试图蒙骗系统(比如:在审核过程中做手脚,盗取用户数据,剽窃其他开发者作品,或者刷评级),你的应用会被下线,开发者身份也会被取消。

这是一篇动态文档,新应用随时都会带来新的规则,你的应用可能就带来下一条规则。

最关键的是,我们非常珍视这个平台,并且尊重您的作品。我们真心要创造一个全球最好的平台,在这里你们可以大展才华,并且以此为生。看起来我们限制了太多的东西,恩,其实是因为,我们承诺用户,他们在apple的设备上享有最佳体验。就像你们也希望的那样。

目录

1.     条款与条件

2.     功能

3.     元数据,评级与分类

4.     位置

5.     提醒推送

6.     游戏中心

7.     iAds

8.     商标权与商品外观

9.     媒体内容

10.   用户接口

11.   购买与传播

12.   废弃与聚合

13.   损坏设备

14.   个人攻击

15.   暴力

16.   负面内容

17.   隐私

18.   色情

19.   宗教,文化和种族

20.   竞猜,赌博,彩券和抽奖

21.   慈善与捐助

22.   法律条件

 

1. 条款与条件

1.1 作为App Store的应用开发者,你受限于如下条款:Program License Agreement (PLA),Human Interface Guidelines (HIG),以及任何你与apple签订的协议和证书。以下规则和示例是为了协助你的应用更快通过审核上架,而不是修正或取代之前的条款。

 

2. 功能

2.1   存在崩溃的应用会被拒。

2.2   存在明显bug的应用会被拒。

2.3   不符合开发者描述的应用会被拒。

2.4   有未说明或隐藏特性或有悖描述的应用会被拒。

2.5   使用非公开API的应用会被拒。

2.6   试图读写非允许范围内的数据的应用会被拒。

2.7   试图以任何方式方法下载代码的应用会被拒。

2.8   安装或运行其他可执行代码的应用会被拒。

2.9   任何“beta”,“demo”,“trial”或“test”版本的应用会被拒。

2.10 iPhone应用必须可以无条件运行在iPad上,支持普通iPhone分辨率和2倍iPhone 3GS分辨率。

2.11 任何与App Store中上架应用重复的应用会被拒,尤其是已经有了很多的:如放屁,打嗝,照明和爱经。

2.12 没有用处的应用,web页面简单组合的应用,或任何哗众取宠,不能提供持续价值的应用会被拒。

2.13 用于市场推广或广告的应用会被拒。

2.14 有意提供隐蔽或虚假功能,却又不能明显标示的应用会被拒。

2.15 大于20MB的应用无法通过蜂窝网络下载安装(App Store自动处理)。

2.16 多任务应用只允许在后谈运行如下服务:VoIP,音频播放,地理位置,任务记录,本地提醒等。

2.17 应用只允许通过iOS WebKit框架和WebKit Javascript访问web页面。

2.18 鼓励酗酒,使用违法药物,或诱导未成年人饮酒,吸烟的应用会被拒。

2.19 提供错误的系统信息或设备数据的应用会被拒。

2.20 通过许多版本的类似应用对App Store造成干扰的开发者会被取消IDP身份。

2.21 歌曲和电影应该提交到iTunes store。书籍应该提交到iBookstore。

2.22 随意通过位置或设备限制用户使用的应用会被拒。

 

3. 元数据(名称,描述,评级,分类等)

3.1   应用或者元数据中提到其他任意移动平台会被拒。

3.2   元数据有未填写项,存留占位符文本会被拒。

3.3   描述中提到与应用内容和功能无关信息会被拒。

3.4   应用在iTunes Connect与设备上显示的名称应该类似,否则会造成混淆。

3.5   不同尺寸的icon要一致,否则会造成混淆。

3.6   图标与截屏不符合4+年龄评级的应用会被拒。

3.7   应用的内容与所选分类和风格不符会被拒。

3.8   开发者有责任把应用放到恰当的评级。不恰当的评级可能会被Apple修改,甚至删除。

3.9   开发者有责任给应用撰写恰当的关键词。不恰当的关键词可能会被Apple修改,甚至删除。

3.10 通过伪造,付费评价或其他非正规手段,获取App Store中较好的评价与星级的开发者会被取消IDP身份。

3.11 任何提示需要用户重启iOS设备来安装或运行的应用会被拒。

3.12 应用在提交审核过程中,所有涉及到的URL都要处于正常运行状态,例如保密协议,相关支持页面等。

 

4. 位置

4.1   未提示用户且获得用户允许之前手机,传输或使用位置数据的应用会被拒。

4.2   使用location-based API来自动控制车辆,飞行器或其他设备的应用会被拒。

4.3   使用location-based API进行调度,队伍管理或应急服务的而应用会被拒。

4.4   位置数据只能用于应用提供的直接相关功能或服务,或者有授权的广告。

 

5. 提醒推送

5.1   不使用APN API提供消息推送的应用会被拒。

5.2   使用APN服务却没从Apple获取一个Push Application ID的应用会被拒。

5.3   在首次推送消息之前取得的用户允许的应用会被拒。

5.4   使用提醒推送服务推送敏感的个人或机密信息的应用会被拒。

5.5   使用提醒推送发送主动消息,欺骗或干扰信息的应用会被拒。

5.6   应用不可以使用提醒推送发送广告,活动或任何形式的直接推广信息。

5.7   应用不可以提供收费的提醒推送服务。

5.8   使用APN服务过度占用网络带宽或容量或通过提醒推送大量占用系统资源的应用会被拒。

5.9   传输病毒,文件,代码或程序,导致破坏或扰乱正常的APN服务操作的应用会被拒。

 

6. 游戏中心

6.1   向终端用户或第三方展示Player ID的应用会被拒。

6.2   Player ID被用于Game Center条款款意外的用途的应用会被拒。

6.3   试图通过Game Center反查,跟踪,描述,关联,发掘,收割,或利用Player ID,别名或其他信息的开发者会被取消IDP身份。

6.4   Game Center信息,例如Leaderboard得分,只能通过Game Center用于应用中。

6.5   使用Game Center发送主动消息,欺骗或干扰信息的应用会被拒。

6.6   使用Game Center过度占用网络带宽或容量的应用会被拒。

6.7   传输病毒,文件,代码或程序,导致破坏或扰乱正常的Game Center操作,的应用会被拒。

 

7. iAds

7.1   人工刷广告浏览或点击率的应用会被拒。

7.2   带有空iAd横幅的应用会被拒。

7.3   设计主要用来展示广告的应用会被拒。

 

8. 商标权与商品外观

8.1   应用必须遵守Guidelines for Using Apple Trademarks and Copyrights 和Apple Trademark List中描述的所有条款和条件。

8.2   任何误导或暗示Apple为该应用来源或提供商,或Apple以任何形式认可其质量或功能的应用会被拒。

8.3   外观与现有Apple产品或广告主题类似或混淆的应用会被拒

8.4   应用名称中出现错误的Apple产品拼写(如,GPS for IPhone, iTunz)的应用会被拒。

8.5   使用受保护的第三方资源(商标,版权,商业机密,以及其他私有内容),请提供一份文本形式的使用授权。

8.6   在保证原有内容的商标特征不被覆盖且完全可见的前提下,应用可以通过Google Maps API调用Google Maps和Google Earth图片。任何遮盖或修改Google标志或版权人证明的应用会被拒。

 

9. 媒体内容

9.1   使用MediaPlayer框架意外的方法访问Music Library中媒体数据的应用会被拒。

9.2   用户界面模仿任何iPod界面的应用会被拒。

9.3   通过蜂窝网络传输的流媒体音频内容不得超过5MB或多余5分钟。

9.4   通过蜂窝网络传输超过10分钟流媒体视频内容,必须使用HTTP Live Streaming,并包涵一条基线64kbps的音频HTTP Live流。

 

10. 用户界面

10.1  应用必须遵守Apple iOS Human Interface Guidelines中的条款和条件。

10.2  外观与iPhone自带应用(如:App Store,iTunes Store和iBookstore)相似的应用会被拒。

10.3  不按照Apple iOS Human Interface Guidelines中的描述正确使用系统控件的应用会被拒。

10.4  试图创建多桌面/主屏环境或模拟多应用工具的应用会被拒。

10.5  修改硬件开关标准功能(例如:音量,震动)的应用会被拒。

10.6  Apple和我们的用户都界面报以很高期望,希望他设计的超级简洁,精致,充满创造力,深思熟虑。做到这些确实会消耗很多精力,但是值得。Apple在这方面要求非常高。如果你的用户界面过于复杂,甚至仅仅是不够好,都可能被拒。

 

11. 购买与流通

11.1  通过App Store以外的渠道解锁或开启附加属性或功能的应用会被拒。

11.2  使用In App Purchase API (IAP)意外的系统提供购买内容,功能或服务的应用会被拒。

11.3  使用IAP为与应用无关的实体商品或商品服务收费的应用会被拒。

11.4  应用使用IAP为信用账户或其他货币收费,必须在应用中消费。

11.5  使用IAP向过期的信用账号或货币收费的应用会被拒。

11.6  使用IAP收费订阅的内容至少要在7天内有效,而且允许在所有iOS设备间共享。

11.7  用到IAP收费项目的应用必须分派到正确的收费类目中。

11.8  使用IAP向用户收费以获取iOS内建功能(如摄像头,陀螺仪)的应用会被拒。

11.9  包涵“出租”内容或服务的应用,在有效期后会被拒。

11.10 保险类应用必须免费,遵守发布地区的法律,不允许使用IAP。

11.11 一般来说,越贵的应用审核就越彻底。

11.12 提供收费订阅的应用必须使用IAP,Apple将会按照Developer Program License Agreement中约定的70/30的比例与开发者分账。

11.13  应用中如果提供了IAP以外的收费或订阅机制,如:“buy”按钮,跳转到一个购买电子书的web页面,会被拒。

11.14  应用可以阅读或播放任何在应用以外取得授权的内容(包括指定的杂志,报纸,书籍,音频,音乐和视频),但在应用中不允许出现获取授权的收费链接或按钮。Apple不会对在应用外订阅或购买授权项目收取任何费用。

 

12. 抓取与整合

12.1  从Apple的页面(如:apple.com, iTunes Store, App Store, iTunes Connect, Apple Developer Programs, 等)抓取内容,或利用Apple页面和服务中的内容进行排名的应用会被拒。

12.2  应用可以使用授权的Apple RSS,例如iTunes Store RSS。

12.3  简单的web页面裁剪,内容整合或链接收集应用会被拒。

 

13. 设备损害

13.1  任何怂恿用户做出可能损坏Apple设备的行为的应用会被拒。

13.2  快速耗光设备电力或产生大量热量的应用会被拒。

 

14. 人身攻击

14.1  任何涉嫌诽谤,侮辱,狭隘内容或打击个人或团体的应用会被拒。

14.2  职业政治讽刺家和幽默作家不受该条款约束。

 

15. 暴力

15.1  展示人或动物被杀戮,致残,枪击,针刺或其他伤害的真实图片的应用会被拒。

15.2  描述暴力或虐待儿童的应用会被拒。

15.3  游戏中的“敌人”不能单独的设定为某特定比赛,文化,真实的政府或组织,或者任何现实事物。

15.4  含有以鼓励非法或鲁莽使用的方式描述真实武器的应用会被拒。

15.5  带有俄罗斯轮盘游戏的应用会被拒。

 

16. 三俗内容

16.1  介绍过度三俗和粗鲁内容的应用会被拒。

16.2  设计来惹怒或恶心用户的应用会被拒。

 

17. 隐私

17.1  在未获得用户事先允许,或未告知用户信息将被如何,在哪里使用的情况下,应用不可以传输用户数据。

17.2  要求用户提供个人信息,如邮箱地址,生日等,才能使用其功能的应用会被拒。

17.3  专门收集未成年人数据的应用会被拒。

 

18. 色情

18.1  含有韦氏词典中定义的色情素材(explicit descriptions or displays of sexual organs or activities intended to stimulate erotic rather than aesthetic or emotional feelings),的应用会被拒。

18.2  经常有用户提供色情内容(例如:Chat Roulette http://en.wikipedia.org/wiki/Chatroulette )的应用会被拒。

 

19. 信仰,文化和种族

19.1  带有对一种信仰,文化或种族进行诽谤,侮辱,狭隘,或以他们为目标的暴力或伤害内容的应用会被拒。

19.2  应用若带有或应用对一种信仰的文字描述,那么这个引用或翻译必须是精确,无歧义的。注释内容可以具有教育性,信息性,但不可以为煽动性。

 

20. 竞赛,赌博,彩票和抽奖

20.1  赌博和竞赛必须是由应用开发者或所有公司发起的。

20.2  应用中必须展示赌博和竞赛的官方条款,并声明Apple不是发起者,并且在任何情况下与此事无关。

20.3  开发者必须经过法律允许才能上线一款抽奖应用,而且抽奖应用必须具备以下要素:报酬,机会,和奖金。

20.4  直接允许用户在应用中购买彩票或抽奖的应用会被拒。

 

21. 慈善与捐助

21.1  含有向已认证的慈善机构捐助功能的应用必须是免费的。

21.2  慈善募捐必须通过短信息或通过Safari访问web页面完成。

 

22. 法律要求

22.1  应用必须遵守所有发布地区当地法律。开发者有义务了解和遵守各地的法律。

22.2  任何带有虚假,欺诈和带有歧义的描述的应用会被拒。

22.3  任何召集,推销和股东犯罪和鲁莽行为的应用会被拒。

22.4  非法文件共享应用会被拒。

22.5  任何设计用来非法赌博,包括算牌,的应用会被拒。

22.6  提供匿名电话或短消息/彩信功能的应用会被拒。

22.7  任何开发暗中获取用户密码和私有数据的开发者会被取消IDP身份。

22.8  任何非法律执行部门发布的带有DUI检查点信息,或鼓励且协助酒后驾车的应用会被拒。

 

动态文档

撰写这篇文档,表示我们尽全力与您分享我们是如何审核提交到App Store的应用的,而且我们希望这个指南能够对您开发和提交应用有所帮助。这是一份动态文档,我们将根据新近应用和情况定期更新这篇文档。

感谢您为iOS开发应用。尽管这是一份“禁止”列表,但请谨记那份更短的“必做”列表。最重要的是,加入我们就是要给用户带来惊喜和愉悦。把世界用最具创意的方式展示给他们,让他们以前所未有的方式生活。根据我们的经验,用户真的会对功能和界面上的改进有所反应。进一步改进你的作品。带给用户超出期望的体验。带给用户前所未有的体验。我们将协助您完成这一切。

© Apple, 2011

 

【译】Emiller Nginx模块开发指南(第二部分)

由于格式问题,这篇文章看起来可能会不太舒服,可以直接阅读我的google doc:

中文版       中英对照版

2. Components of an Nginx Module

2. nginx模块的各个组件

 

As I said, you have a lot of flexibility when it comes to making an Nginx module. This section will describe the parts that are almost always present. It's intended as a guide for understanding a module, and a reference for when you think you're ready to start writing a module.

正如我所说的,开发一个nginx模块的时候,具有非常非常强的灵活性。这部分就介绍一下这些东西。类似于理解模块的一个指南或者是你觉得你已经准备好开始开发模块的时候的一个参考资料。(译注:这一部分是最重要的,而且在日后的开发中,这部分可以当作字典来用)

 

2.1. Module Configuration Struct(s)

2.1. 模块配置结构

- 阅读剩余部分 -

【译】Emiller Nginx模块开发指南(第一部分)

这篇文章被认为是nginx模块开发的标准教程,因此翻译过来希望对大家有所帮助。

原文链接:http://www.evanmiller.org/nginx-modules-guide.html

这一部分介绍了nginx的一些基础知识,对已经熟悉nginx的开发者帮助不大,但如果初识nginx,建议还是好好读一下,并且最好能有所扩展。

 

由于格式问题,这篇文章看起来可能会不太舒服,可以直接阅读我的google doc:

中文版       中英对照版

Emiller's Guide To Nginx Module Development

Emiller Nginx模块开发指南

By Evan Miller    作者:Evan Miller

 

DRAFT: August 13, 2009 (changes)

Bruce Wayne: What's that?

Lucius Fox: The Tumbler? Oh... you wouldn't be interested in that.

To fully appreciate Nginx, the web server, it helps to understand Batman, the comic book character.

Batman is fast. Nginx is fast. Batman fights crime. Nginx fights wasted CPU cycles and memory leaks. Batman performs well under pressure. Nginx, for its part, excels under heavy server loads.

But Batman would be almost nothing without the Batman utility belt.

作者上来先来了一段废话说nginx巨像蝙蝠侠,都很快什么什么的,而且nginx还能把cpu和内存处理的巨牛B,并且在巨大的压力下还能很happy的工作。但是蝙蝠侠是要靠一个腰带的,没了腰带蝙蝠侠就不行了。

 

Figure 1: The Batman utility belt, gripping Christian Bale's love handles.

特点1:蝙蝠侠腰带什么的

 

At any given time, Batman's utility belt might contain a lock pick, several batarangs, bat-cuffs, a bat-tracer, bat-darts, night vision goggles, thermite grenades, smoke pellets, a flashlight, a kryptonite ring, an acetylene torch, or an Apple iPhone. When Batman needs to tranquilize, blind, deafen, stun, track, stop, smoke out, or text-message the enemy, you better believe he's reaching down for his bat-belt. The belt is so crucial to Batman's operations that if Batman had to choose between wearing pants and wearing the utility belt, he would definitely choose the belt. In fact, he *did* choose the utility belt, and that's why Batman wears rubber tights instead of pants (Fig. 1).

对蝙蝠侠腰带感兴趣的同学,请去看电影,这一段不翻译,主要原因是看不懂。。。

- 阅读剩余部分 -

[译]Cassandra内部架构

最近想看看Cassandra的源码,于是去看他们的wiki,先把一个概述翻了,当誓师,hoho

原文链接:http://wiki.apache.org/cassandra/ArchitectureInternals

General

概述

Configuration file is parsed by DatabaseDescriptor (which also has all the default values, if any)

DatabaseDescriptor是专门解析配制文件的,配制的默认值也跟这定义。

Thrift generates an API interface in Cassandra.java; the implementation is CassandraServer, and CassandraDaemon ties it together. 

Cassandra.java调用Thrift(一个apache的跨语言框架)产生一个API接口,CassandraServer负责实现,CassandraDaemon把二者联系起来。

CassandraServer turns thrift requests into the internal equivalents, then StorageProxy does the actual work, then CassandraServer turns it back into thrift again

CassandraServer把thrift请求丢到一个内部容器里,然后StorageProxy来完成具体的工作,CassandraServer再把它拿回到thrift。

StorageService is kind of the internal counterpart to CassandraDaemon. It handles turning raw gossip into the right internal state.

StorageService是一个类似内部CassandraDaemon的玩艺儿。它就是为了让那些还没处理过的请求待在他们应该在的位置上。

AbstractReplicationStrategy controls what nodes get secondary, tertiary, etc. replicas of each key range. Primary replica is always determined by the token ring (in TokenMetadata) but you can do a lot of variation with the others. RackUnaware just puts replicas on the next N-1 nodes in the ring. RackAware puts the first non-primary replica in the next node in the ring in ANOTHER data center than the primary; then the remaining replicas in the same as the primary.

AbstractReplicationStrategy控制节点等级。每一个键的副本都有顺序。主副本是由定义在TokenMetadata里的token ring决定的,但是在其他副本上你可以有很大的发挥空间。RackUnaware只负责把副本送到环上另外N-1个节点。RackAware把把第一个非主副本放到不同于主副本的另外一个数据中心的后续节点上;剩下的副本就跟主副本在一起了。

MessagingService handles connection pooling and running internal commands on the appropriate stage (basically, a threaded executorservice). Stages are set up in StageManager; currently there are read, write, and stream stages. (Streaming is for when one node copies large sections of its sstables to another, for bootstrap or relocation on the ring.) The internal commands are defined in StorageService; look for registerVerbHandlers.

MessagingService统筹链接并在合适的阶段运行内部命令(其实就是个线程池)。各个阶段由StageManager发起;目前包括读,写和流阶段。(流,是当一个节点需要拷贝一个大段数据到另外的节点时,提供环上的引导和重定位。)内部命令在StorageService中定义,参考registerVerbHandlers。

- 阅读剩余部分 -

[译]最终一致性

前几天在网上看到了这篇amazon CTO Werner Vogels的文章,讲分布系统最终一致性的,特意翻过来,学习

Eventually Consistent – Revisited

最终一致

By Werner Vogels

http://www.allthingsdistributed.com/2008/12/eventually_consistent.html

I wrote a first version of this posting on consistency models about a year ago, but I was never happy with it as it was written in haste and the topic is important enough to receive a more thorough treatment. ACM Queue asked me to revise it for use in their magazine and I took the opportunity to improve the article. This is that new version.

一年前我首次发表这篇关于一致性模型的文章,但郁闷的是那篇文章写得太仓促,而且这个主题很大,本应该投入更多精力。ACM Queue(一本很牛B的杂志,ACM办的,http://queue.acm.org/ )希望我能够修改一下这篇文章,他们杂志可以用。我答应了他们,一举两得,这样还可以有机会去完善我的文章。以下是这篇文章的新版本。

Eventually Consistent - Building reliable distributed systems at a worldwide scale demands trade-offs between consistency and availability.

最终一致——在世界范围搭建一个可靠的分布式系统,就要求我们在一致性和可用性上进行权衡,取舍。

At the foundation of Amazon's cloud computing are infrastructure services such as Amazon's S3 (Simple Storage Service), SimpleDB, and EC2 (Elastic Compute Cloud) that provide the resources for constructing Internet-scale computing platforms and a great variety of applications. The requirements placed on these infrastructure services are very strict; they need to score high marks in the areas of security, scalability, availability, performance, and cost effectiveness, and they need to meet these requirements while serving millions of customers around the globe, continuously.

创建亚马逊云计算的时候我们的定位是,一个像亚马逊S3(Simple Storage Service)、Simple DB和EC2(Elastic Compute Cloud)一样的基础设施,他可以提供资源,搭建全网范围的计算平台和大量应用。对这些基础设施的要求是很苛刻的,他们需要在安全性、伸缩性、可用性、性能和性价比上都有上佳的表现,而且要知道,所有的这些要求是建立在不间断的为全球数百万用户提供服务的基础上的。

Under the covers these services are massive distributed systems that operate on a worldwide scale. This scale creates additional challenges, because when a system processes trillions and trillions of requests, events that normally have a low probability of occurrence are now guaranteed to happen and need to be accounted for up front in the design and architecture of the system. Given the worldwide scope of these systems, we use replication techniques ubiquitously to guarantee consistent performance and high availability. Although replication brings us closer to our goals, it cannot achieve them in a perfectly transparent manner; under a number of conditions the customers of these services will be confronted with the consequences of using replication techniques inside the services.

在这些服务的背后是一个存在于世界范围的庞大的分布系统。这种庞大的规模带来很多额外的挑战,由于当一个系统要处理数以万亿计的请求时,正常情况下的小概率事件在这里就可能被认为是必然事件,而且要在设计和构建系统之前就考虑到。考虑到这些系统是世界级规模的,我们无处不在使用冗余技术来保证一致性能和高可用性。虽然冗余让我们更容易达成目标,但这不是一个完美的,清晰的方法;在大量不相同的条件下,这些服务的用户将会面临服务内部冗余技术带来的不良结果。

One of the ways in which this manifests itself is in the type of data consistency that is provided, particularly when the underlying distributed system provides an eventual consistency model for data replication. When designing these large-scale systems at Amazon, we use a set of guiding principles and abstractions related to large-scale data replication and focus on the trade-offs between high availability and data consistency. In this article I present some of the relevant background that has informed our approach to delivering reliable distributed systems that need to operate on a global scale. An earlier version of this text appeared as a posting on the All Things Distributed weblog in December 2007 and was greatly improved with the help of its readers.

解决这个问题的一个途径就是在系统提供的数据一致性类型中声明自己,尤其是当底层分布式系统为数据冗余提供最终一致性模型的时候。在亚马逊设计这些大规模系统,我们使用了一系列的定向原理和大规模数据冗余的抽象关系,并且关注高可用性和数据一致性之间的取舍。本文我提到了一些有关背景,这些是我们即将应用在全球规模的分布式系统上的。本文2007年12月,较早的那个版本在读者的帮助下有了很大的提高。

- 阅读剩余部分 -