<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>普罗之家</title>
	<atom:link href="http://www.procty.com/?feed=rss2" rel="self" type="application/rss+xml" />
	<link>http://www.procty.com</link>
	<description>放松……放松……虚领顶劲、含胸拔背，心神内敛、存想自然…………</description>
	<lastBuildDate>Fri, 27 Aug 2010 06:22:58 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>SelectionKey.OP_CONNECT与channel.isConnected()</title>
		<link>http://www.procty.com/?p=180</link>
		<comments>http://www.procty.com/?p=180#comments</comments>
		<pubDate>Fri, 27 Aug 2010 06:22:58 +0000</pubDate>
		<dc:creator>普罗</dc:creator>
				<category><![CDATA[Java]]></category>
		<category><![CDATA[TD3C]]></category>

		<guid isPermaLink="false">http://www.procty.com/?p=180</guid>
		<description><![CDATA[这是java的一个bug。表现为OP_CONNECT操作发生的时候channel.isConnected()为false。
官方做出的解决方案是OP_CONNECT发生的时候调用socketChannel.finishConnect()操作。
这个问题折腾了我整一天，他娘的居然还有这种说法。
]]></description>
		<wfw:commentRss>http://www.procty.com/?feed=rss2&amp;p=180</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>无限地图实现，无限大的地图实现原理</title>
		<link>http://www.procty.com/?p=176</link>
		<comments>http://www.procty.com/?p=176#comments</comments>
		<pubDate>Mon, 05 Jul 2010 01:37:37 +0000</pubDate>
		<dc:creator>普罗</dc:creator>
				<category><![CDATA[星海传奇]]></category>

		<guid isPermaLink="false">http://www.procty.com/?p=176</guid>
		<description><![CDATA[终于，在前天把地图做出来了。
它是一个无限大的可自动扩充的地图。理论上它可以管理的区域为2^63 * 2^63 格。格这个单位可以是像素，格子，或者其他。
实现原理是树，使用树形结构从根一路扩展到树叶，自动搜索，自动添加节点。
每个地图区域的获得需要17个节点的搜索，效率上看似乎有些地方浪费了，不过可以从缓存方向解决这个不足。
地图的存储使用nosql数据库，所以它支撑这种存储方式。
]]></description>
		<wfw:commentRss>http://www.procty.com/?feed=rss2&amp;p=176</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>星海传奇，世界模拟器</title>
		<link>http://www.procty.com/?p=170</link>
		<comments>http://www.procty.com/?p=170#comments</comments>
		<pubDate>Wed, 02 Jun 2010 13:33:34 +0000</pubDate>
		<dc:creator>普罗</dc:creator>
				<category><![CDATA[星海传奇]]></category>

		<guid isPermaLink="false">http://www.procty.com/?p=170</guid>
		<description><![CDATA[如果抛弃玩家的操作接口，星海传奇就是一个自然发展的世界，当然需要给里面每一个功能单位添加AI。
世界的主体是星系，星系内有各种对象，主要的对象是移动要塞，次要的是NPC，再其次的是星系物体。
模拟要素一，地图：
星系很大，需要保存的东西虽然不多，但为了可能存在的无限扩展地图，需要定义一种高可扩展的地图。我在之前的博客有介绍过。
模拟要素二，时间：
既然是一个世界，那么我们需要处理世界中的大大小小的对象行为，时间控制以任务的形式，由任务调度来执行。
模拟要素三，事件：
世界中对象的状态改变由监听器来交互，感兴趣则监听状态否则不管。
模拟要素四，对象：
世界基本对象构成，星海传奇中，数据存储以对象为基本单位，基本处理单位也是对象。
]]></description>
		<wfw:commentRss>http://www.procty.com/?feed=rss2&amp;p=170</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>面向海量服务的设计原则和策略总结</title>
		<link>http://www.procty.com/?p=167</link>
		<comments>http://www.procty.com/?p=167#comments</comments>
		<pubDate>Thu, 27 May 2010 10:41:40 +0000</pubDate>
		<dc:creator>普罗</dc:creator>
				<category><![CDATA[数据存储]]></category>

		<guid isPermaLink="false">http://www.procty.com/?p=167</guid>
		<description><![CDATA[转自javaEye：

互联网服务的特点就是面向海量级的用户，面向海量级的用户如何提供稳定的服务呢？这里，对这几年的一些经验积累和平时接触的一些理念做一个总结。
一、原则
1．Web服务的CAP原理
CAP是指的是三个要素：一致性(Consistency)、可用性(Availability)、分区容忍性(Partition tolerance)。CAP原理指的是这三个要素最多只能同时实现两点，不可能三者兼顾，对于海量级服务，一般这是一条常记心中的基准准则。
如下是《Web服务的CAP 》关于CAP的定义：

一致性：可以参考数据库的一致性。每次信息的读取都需要反映最新更新后的数据。
可用性：高可用性意味着每一次请求都可以成功完成并受到响应数据
分区宽容度：这个是容错机制的要求。一个服务需要在局部出错的情况下，没有出错的那部分被复制的数据分区仍然可以支持部分服务的操作，可以简单的理解为可以很容易的在线增减机器以达到更高的扩展性，即所谓的横向扩展能力。

面向海量级的分布式服务设计，基本上分区容忍性(Partition tolerance)是第一要素，因此根据业务的情况，我们需要在一致性(Consistency)和可用性(Availability)之间做取舍。对于一些业务，譬如支付宝或财付通，一致性会是第一考虑要素，即使是延迟的不一致也是不可接受的，这种时候只能牺牲可用性以保证一致性。对于一些应用，譬如淘宝或拍拍交易中的评价信息，一般用户是可以接受延迟的一致性，这种时候可以优先考虑可用性，而用最终一致性来保证数据一致，譬如通过某种对帐机制。对于一些应用，甚至一致性都并非要求，只需要保证差不多一致性即可，譬如Q-zone中的农场游戏中的偷菜。
根据我们应用的业务需求，选择合适的一致性级别，以更好地保证系统的分区容忍性和可用性。
2．柔性可用
面向海量级的分布式服务设计，我们要意识到，一切都是不可靠的，在不可靠的环境的环境中构建可靠的应用，其中最重要的一点就是保持系统的柔性。
1）不可靠的环境
我们可能已经见惯一个远程服务提供不了服务了，运行一段时间后WebServer突然不响应了，数据库随着负载的不断增加再放上一条SQL语句就会垮掉。但是，硬盘坏掉、电源断掉、光纤中断，听起来似乎多么不可思议，然而，当一个海量服务需要成千上万台服务器、需要部署全国各地的数十个数据中心、需要横跨电信网通教育网三大网络的时候，一切听起来不可思议的事情会变成常态。一切都是不可靠的，唯一可靠的就是不可靠本身。
2）划分服务级别
我们应该意识到，在这种不可靠的环境中提供完美的服务，本身就是一个神话，即使不是说完全不可能，但至少是代价高昂的，因此，当某些问题发生（环境变地不可靠的时候），我们必须做出取舍，选择为用户提供用户最关心的服务，这种服务虽然听起来是有损的（至少是不完美的），但却能在一定程度上满足用户大部分的需求。譬如，当网络带宽无法为用户提供最好的体验而扩容又不是短期可以达到的时候，选择降低一些非重要服务的体验是一个比较好的选择。
在面向海量互联网的设计当中，对服务进行分级，当系统变地不可靠的时候，优先提供重要优先级的服务。
3）尽快响应
互联网用户的耐心是非常有限的，如果一个页面需要3秒以上才能看到，也许大部分用户的第一选择就是关掉浏览器。在构建柔性可用的互联网服务的时候，响应时间大部分情况下都是需要最优先考虑。还是一句话，环境是不可靠的，当我们无法尽快从远程服务获得数据、当数据库已经慢如蜗牛，也许当后台还在吭哧吭哧干活的时候，用户老早已经关闭了页面，处理返回的数据也只是在浪费表情，面向互联网用户，响应就是生命。
二、策略
如何让我们的应用提供更高质量的服务呢，这里是一些在日常开发使用到或者观察到的一些策略的总结：
1．数据sharding
海量服务相应也意味着海量的用户和海量的用户数据，大家都知道，即使是再强大的数据库、再强大服务器，在单表上亿规模的数据足够让一条简单的SQL语句慢如蜗牛（甚至于在百万、千万级别上，如果没有采取合适的策略，都无法满足服务要求），一般处理这种千万上亿级数据的大家基本上都会想到的就是数据sharding，将数据切割成多个数据集，分散到多个数据库的多个表中（譬如将用户数据按用户ID切割成4个数据库每个数据库100个表共400个表），由于每个表数据足够小可以让我们的SQL语句快速地执行。而至于如何切割，实际上跟具体的业务策略有关系。
当然，我们要认识到，这种数据sharding并非全无代价的，这也意味着我们需要做出一些折中，譬如可能很难进行跨表数据集的查询、联表和排序也变地非常困难、同时数据库client程序编写也会变地更加复杂、保证数据一致性在某些情况下会变地困难重重。sharding并非万能药，选择是否sharding、如何sharding、为sharding如何换用一个近似的业务描述方式，这是业务设计需要仔细考虑的问题。
2．Cache
经验会告诉我们，基本上大部分系统的瓶颈会集中在IO/数据库上，常识也告诉我们，网络和内存的速度比IO/数据库会提升甚至不止一个数量级。面向海量服务，Cache基本上是一个必选项，分布式Cache更是一个不二选择，根据我们的需要，我们可以选择memcached（非持久化）、memcachedb/Tokyo Tyrant（持久化），甚至构建自己的cache平台。
在使用Cache上，下面是需要仔细考虑的点：

选择合适的Cache分布算法，基本上我们会发现使用取模方式决定Cache位置是不可靠的，因为坏节点的摘除或者节点扩量会让我们的Cache命中率在短时间内下降到冰点，甚至会导致系统在短期内的负载迅速增长甚至于崩溃，选择一种合适的分布算法非常重要，譬如稳定的一致性哈希
选择在哪层上进行Cache，譬如数据层Cache、应用层Cache和Web层Cache，越靠近数据，Cache的通用性越高，越容易保持Cache数据的一致性，但相应的处理流程也越长，而越靠近用户，Cache的通用性越差，越难保证Cache数据的一致性，但是响应也越快，根据业务的特点，选择合适的Cache层是非常重要的。一般而言，我们会选择将粗粒度、极少变更、数据对用户不敏感（即可以一定程度上接受误差）、并且非针对用户级的数据，在最靠近用户的层面上Cache，譬如图片Cache、TOP X等数据；而将一些细粒度、变更相对频繁、用户相对敏感的数据或者是针对用户级的数据放在靠近数据的一段，譬如用户的Profile、关系链等。

3．服务集群
面向海量服务，系统的横向扩展基本上是第一要素，在我的经验和经历中，服务集群需要考虑如下因素：

分层：合理地对系统进行分层，将系统资源要求不同的部分进行合理地逻辑/物理分层，一般对于简单业务，Client层、WebServer层和DB层已经足够，对于更复杂业务，可能要切分成Client层、WebServer层、业务层、数据访问层（业务层和数据访问层一般倾向于在物理上处于同一层）、数据存储层（DB），太多的分层会导致处理流程变长，但相应系统地灵活性和部署性会更强。
功能细粒度化：将功能进行细粒度的划分，并使用独立的进程部署，一方面能更有利于错误的隔离，另一方面在功能变更的时候避免一个功能对其他功能产生影响
按数据集部署：如果每一层都允许对下一层所有的服务接口进行访问，将存在几个严重的缺陷，一是随着部署服务的增长，会发现下一层必须允许数量非常庞大的Socket连接进来，二是我们可能必须把不同的服务部署在不同的数据中心(DC)的不同机房上，即便是上G的光纤专线，机房间的穿梭流量也会变地不可接受，三是每个服务节点都是全数据容量接入，并不利于做一些有效的内部优化机制，四是只能采用代码级控制的灰度发布和部署。当部署规模达到一定数量级的时候，按数据集横向切割成多组服务集合，每组服务集合只为特定的数据集服务，在部署上，每组服务集合可以部署在独立的相同的数据中心(DC)上。
无状态：状态将为系统的横向扩容带来无穷尽的烦恼。对于状态信息比少的情况，可以选择将全部状态信息放在请求发器端，对于状态信息比较多的情况，可以考虑维持一个统一的Session中心。
选择合适的负载均衡器和负载均衡策略：譬如在L4上负载均衡的LVS、L7上负载均衡的Nginx、甚至是专用的负载均衡硬件F5（L4），对于在L7上工作的负载均衡器，选择合适的负载均衡策略也非常重要，一般让用户总是负载均衡到同一台后端Server是一个很好的方式

4．灰度发布
当系统的用户增长到一定的规模，一个小小功能的发布也会产生非常大的影响，这个时候，将功能先对一小部分用户开放，并慢慢扩展到全量用户是一个稳妥的做法，使用灰度化的发布将避免功能的BUG产生大面积的错误。如下是一些常见的灰度控制策略：

白名单控制：只有白名单上的用户才允许访问，一般用于全新功能Alpha阶段，只向被邀请的用户开放功能
准入门槛控制：常见的譬如gmail出来之初的邀请码、QQ农场开始阶段的X级的黄钻准入，同样一般用于新功能的Beta阶段，慢慢通过一步一步降低门槛，避免在开始之处由于系统可能潜在的问题或者容量无法支撑导致整个系统的崩溃。
按数据集开放：一般常用于成熟的功能的新功能开发，避免新功能的错误产生大面积的影响

5．设计自己的通信协议：二进制协议、向上/下兼容
随着系统的稳定运行访问量的上涨，慢慢会发现，一些看起来工作良好的协议性能变地不可接受，譬如基于xml的协议xml-rpc，将会发现xml解析和包体的增大变地不可接受，即便是接近于二进制的hessian协议，多出来的字段描述信息(按我的理解，hessian协议是类似于map结构的，包含字段的名称信息)和基于文本的http头将会使协议效率变地低下。也许，在开始合适的时候而不是到最后不得已的时候，去设计一个良好的基于二进制的高效的内部通信协议是一个好的方式。按我的经验，设计自己的通信协议需要注意如下几点：

协议紧凑性，否则早晚你会为你浪费的空间痛心疾首
协议扩展性，早晚会发现旧的协议格式不能适应新的业务需求，而在早期预留变地非常地重要，基本上，参见一些常用的规范，魔术数（对于无效果的请求可以迅速丢弃）、协议版本信息、协议头、协议Body、每个部分（包括结构体信息中的对象）的长度这些信息是不能省的
向下兼容和向上兼容：但功能被大规模地调用的时候，发布一个新的版本，让所有的client同时升级基本上是不可接受的，因此在设计之处就需要考虑好兼容性的问题

6．设计自己的Application Server
事情进行到需要自己设计通信协议，自己构建Application Server也变地顺理成章，下面是在自己开发Application Server的时候需要处理的常见的问题：

过载保护：当系统的某个部件出现问题的时候，最常见的情况是整个系统的负载出现爆炸性的增长而导致雪崩效应，在设计application server的时候，必须注意进行系统的过载保护，当请求可以预期无法处理的时候(譬如排队满载或者排队时间过长)，丢弃是一个明智的选择，TCP的backlog参数是一个典型的范例。
频率控制：即便是同一系统中的其他应用在调用，一个糟糕的程序可能会将服务的所有资源占完，因此，应用端必须对此做防范措施，频率控制是其中比较重要的一个
异步化/无响应返回：对于一些业务，只需要保证请求会被处理即可，客户端并不关心什么时候处理完，只要最终保证处理就行，甚至最终没有处理也不是很严重的事情，譬如邮件，对于这种应用，应快速响应避免占着宝贵的连接资源，而将请求进入异步处理队列慢慢处理。
自我监控：Application Server本身应该具备自我监控的功能，譬如性能数据采集、为外部提供内部状态的查询（譬如排队情况、处理线程、等待线程）等
预警：譬如当处理变慢、排队太多、发生请求丢弃的情况、并发请求太多的时候，Application Server应该具备预警的能力以快速地对问题进行处理

7．Client
很多应用会作为服务的Client，去调用其他的服务，如下是在做为Client应该注意的一些问题：

服务不可靠：作为Client永远要记住的一点就是，远程服务永远是不可靠的，因此作为Client自己要注意做自我保护，当远程服务如果无法访问时，做折中处理
超时保护：还是上面所说的，远程服务永远都是不可靠的，永远也无法预测到远程什么时候会响应，甚至可能不会响应（譬如远程主机宕机），请求方要做好超时保护，譬如对于主机不可达的情况，在linux环境下，有时会让客户端等上几分钟TCP层才会最终告诉你服务不可到达。
并发/异步：为了提速响应，对于很多可以并行获取的数据，我们总是应该并行地去获取，对于一些我们无法控制的同步接口——譬如读数据库或同步读cache——虽然不是很完美，但多线程并行去获取是一个可用的选择，而对于服务端都是使用自构建的Application Server，使用异步Client接口至关重要，将请求全部发送出去，使用异步IO设置超时等待返回即可，甚至于更进一步异步anywhere，在将client与application server整合到一块的时候，请求发送出去之后立即返回，将线程/进程资源归还，而在请求响应回来符合条件的时候，触发回调做后续处理。

8．监控和预警
基本上我们会见惯了各种网络设备或服务器的监控，譬如网络流量、IO、CPU、内存等监控数据，然而除了这些总体的运行数据，应用的细粒度化的数据也需要被监控，服务的访问压力怎么样、处理速度怎么样、性能瓶颈在哪里、带宽主要是被什么应用占、Java虚拟机的CPU占用情况怎么样、各内存区的内存占用情况如何，这些数据将有利于我们更好的了解系统的运行情况，并对系统的优化和扩容提供数据指导。
除了监控，有效的预警机制也是必不可少，应用是否在很好地提供服务、响应时间是否能够达到要求、系统容量是否达到一个阀值。有效的预警机制将让我们尽快地对问题进行处理。
9．配置中心化
当系统错误的时候，我们如何尽快地恢复呢，当新增服务节点的时候，如何尽快地让真个系统感知到呢？当系统膨胀之后，如果每次摘除服务节点或者新增节点都需要修改每台应用配置，那么配置和系统的维护将变地越来越困难。
配置中心化是一个很好的处理这个问题的方案，将所有配置进行统一地存储，而当发生变更的时候（摘除问题节点或者扩量增加服务节点或新增服务），使用一些通知机制让各应用刷新配置。甚至于，我们可以自动地检测出问题节点并进行智能化的切换。
三、最后
构建面向海量用户的服务，可以说是困难重重挑战重重，一些原则和前人的设计思路可以让我们获得一些帮助，但是更大的挑战会来源于细节部分，按我们技术老大的说法，原则和思路只要看几本书是个技术人员都会，但决定一个系统架构师能力的，往往却是对细节的处理能力。因此，在掌握原则和前人的设计思路的基础上，更深入地挖掘技术的细节，才是面向海量用户的服务的制胜之道。
]]></description>
		<wfw:commentRss>http://www.procty.com/?feed=rss2&amp;p=167</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Eclipse快捷键</title>
		<link>http://www.procty.com/?p=165</link>
		<comments>http://www.procty.com/?p=165#comments</comments>
		<pubDate>Thu, 20 May 2010 07:37:35 +0000</pubDate>
		<dc:creator>普罗</dc:creator>
				<category><![CDATA[未分类]]></category>

		<guid isPermaLink="false">http://www.procty.com/?p=165</guid>
		<description><![CDATA[Ctrl+1 快速修复Ctrl+D: 删除当前行
Alt+↓ 当前行和下面一行交互位置Alt+↑ 当前行和上面一行交互位置Alt+← 前一个编辑的页面Alt+→ 下一个编辑的页面
Alt+Enter 显示当前选择资源(工程,or 文件 or文件)的属性
Shift+Enter 在当前行的下一行插入空行(这时鼠标可以在当前行的任一位置,不一定是最后)Shift+Ctrl+Enter 在当前行插入空行(原理同上条)
Ctrl+Q 定位到最后编辑的地方Ctrl+L 定位在某行 (对于程序超过100的人就有福音了)Ctrl+M 最大化当前的Edit或View (再按则反之)Ctrl+/ 注释当前行,再按则取消注释Ctrl+O 快速显示 OutLineCtrl+T 快速显示当前类的继承结构Ctrl+W 关闭当前EditerCtrl+K 参照选中的Word快速定位到下一个Ctrl+E 快速显示当前Editer的下拉列表(如果当前页面没有显示的用黑体表示)
Ctrl+/(小键盘) 折叠当前类中的所有代码
Ctrl+×(小键盘) 展开当前类中的所有代码
Ctrl+Space 代码助手完成一些代码的插入(但一般和输入法有冲突,可以修改输入法的热键,也可以暂用Alt+/来代替)
Ctrl+Shift+E 显示管理当前打开的所有的View的管理器(可以选择关闭,激活等操作)
Ctrl+J 正向增量查找(按下Ctrl+J后,你所输入的每个字母编辑器都提供快速匹配定位到某个单词,如果没有,则在stutes line中显示没有找到了,查一个单词时,特别实用,这个功能Idea两年前就有了)
Ctrl+Shift+J 反向增量查找(和上条相同,只不过是从后往前查)
Ctrl+Shift+F4 关闭所有打开的Editer
Ctrl+Shift+X 把当前选中的文本全部变味小写
Ctrl+Shift+Y 把当前选中的文本全部变为小写
Ctrl+Shift+F 格式化当前代码
Ctrl+Shift+P 定位到对于的匹配符(譬如{}) (从前面定位后面时,光标要在匹配符里面,后面到前面,则反之)
下面的快捷键是重构里面常用的,本人就自己喜欢且常用的整理一下(注:一般重构的快捷键都是Alt+Shift开头的了)
Alt+Shift+R 重命名 (是我自己最爱用的一个了,尤其是变量和类的Rename,比手工方法能节省很多劳动力)
Alt+Shift+M 抽取方法 (这是重构里面最常用的方法之一了,尤其是对一大堆泥团代码有用)
Alt+Shift+C 修改函数结构(比较实用,有N个函数调用了这个方法,修改一次搞定)
Alt+Shift+L 抽取本地变量( 可以直接把一些魔法数字和字符串抽取成一个变量,尤其是多处调用的时候)
Alt+Shift+F 把Class中的local变量变为field变量 (比较实用的功能)
Alt+Shift+I 合并变量(可能这样说有点不妥Inline)Alt+Shift+V 移动函数和变量(不怎么常用)Alt+Shift+Z 重构的后悔药(Undo)
]]></description>
		<wfw:commentRss>http://www.procty.com/?feed=rss2&amp;p=165</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>该改一改不切实际的想法了</title>
		<link>http://www.procty.com/?p=162</link>
		<comments>http://www.procty.com/?p=162#comments</comments>
		<pubDate>Thu, 20 May 2010 07:29:52 +0000</pubDate>
		<dc:creator>普罗</dc:creator>
				<category><![CDATA[星海传奇]]></category>

		<guid isPermaLink="false">http://www.procty.com/?p=162</guid>
		<description><![CDATA[忽然发现，我对项目的要求太宽太泛了，好像不一次开发出承载100W同时在线就不能活似的，搞到现在，结果就是阻碍重重却无法看到产品。
我该检讨，该改变做事方法，由小到大，积少成多。
星海传奇在我的脑海中是个奇大的世界，可是它需要解决的技术问题不是几天就能解决的。好吧，我会做个规划，将可替换的东西使用简单的实现或者开源项目来解决。到了该为星海传奇添加roadmap的时候了。
]]></description>
		<wfw:commentRss>http://www.procty.com/?feed=rss2&amp;p=162</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>NoSQL数据库笔谈</title>
		<link>http://www.procty.com/?p=158</link>
		<comments>http://www.procty.com/?p=158#comments</comments>
		<pubDate>Tue, 18 May 2010 01:38:14 +0000</pubDate>
		<dc:creator>普罗</dc:creator>
				<category><![CDATA[数据存储]]></category>

		<guid isPermaLink="false">http://www.procty.com/?p=158</guid>
		<description><![CDATA[
NoSQL数据库笔谈
颜开
v0.2
2010.2
http://docs.google.com/View?id=dc23&#215;53c_64db5px4f6



序
思想篇

CAP
最终一致性

变体


BASE
其他

I/O的五分钟法则
不要删除数据
RAM是硬盘,硬盘是磁带
Amdahl定律和Gustafson定律
万兆以太网




手段篇

一致性哈希



亚马逊的现状
算法的选择




Quorum NRW
Vector clock
Virtual node
gossip

Gossip (State Transfer Model)
Gossip (Operation Transfer Model)


Merkle tree
Paxos

背景


DHT
Map Reduce Execution
Handling Deletes
存储实现
节点变化
列存

描述
特点




软件篇

亚数据库

MemCached

特点
内存分配
缓存策略
缓存数据库查询
数据冗余与故障预防
Memcached客户端（mc）
缓存式的Web应用程序架构
性能测试


dbcached

Memcached 和 dbcached 在功能上一样吗?




列存系列

Hadoop之Hbase
耶鲁大学之HadoopDB
GreenPlum
FaceBook之Cassandra

Cassandra特点
Keyspace
Column family（CF）
Key
Column
Super column
Sorting
存储
API


Google之BigTable
Yahoo之PNUTS

特点
PNUTS实现

Record-level mastering 记录级别主节点
PNUTS的结构
Tablets寻址与切分
Write调用示意图


PNUTS感悟


微软之SQL数据服务


非云服务竞争者
文档存储

CouchDB

特性


Riak
MongoDB
Terrastore
ThruDB


Key Value / Tuple 存储

Amazon之SimpleDB
Chordless
Redis
Scalaris
Tokyo cabinet / Tyrant
CT.M
Scalien
Berkley DB
MemcacheDB
Mnesia
LightCloud
HamsterDB
Flare


最终一致性Key Value存储

Amazon之Dynamo

功能特色
架构特色


BeansDB

简介
更新
特性
性能


Nuclear

两个设计上的Tips


Voldemort
Dynomite
Kai


未分类

Skynet
Drizzle


比较

可扩展性
数据和查询模型
持久化设计




应用篇

eBay 架构经验
淘宝架构经验
Flickr架构经验
Twitter运维经验

运维经验

Metrics
配置管理
Darkmode
进程管理
硬件


代码协同经验

Review制度
部署管理
团队沟通


Cache


云计算架构
反模式

单点失败（Single Point of Failure）
同步调用
不具备回滚能力
不记录日志
无切分的数据库
无切分的应用
将伸缩性依赖于第三方厂商


OLAP

OLAP报表产品最大的难点在哪里？


NOSQL们背后的共有原则

假设失效是必然发生的
对数据进行分区
保存同一数据的多个副本
动态伸缩
查询支持
使用 Map/Reduce 处理汇聚
基于磁盘的和内存中的实现
仅仅是炒作?




附

感谢
版本志
引用




序
日前国内没有一套比较完整的NoSQL数据库资料，有很多先驱整理发表了很多，但不是很系统。不材尝试着将各家的资料整合一下，并书写了一些自己的见解。
本书写了一些目前的NoSql的一些主要技术，算法和思想。同时列举了大量的现有的数据库实例。读完全篇，相信读者会对NoSQL数据库了解个大概。
另外我还准备开发一个开源内存数据库galaxydb.本书也是为这个数据库提供一些架构资料。
思想篇
CAP，BASE和最终一致性是NoSQL数据库存在的三大基石。而五分钟法则是内存数据存储了理论依据。这个是一切的源头。
CAP




C: Consistency 一致性
A: Availability 可用性(指的是快速获取数据)
P: Tolerance of network Partition 分区容忍性(分布式)

10年前，Eric Brewer教授指出了著名的CAP理论，后来Seth Gilbert 和 Nancy lynch两人证明了CAP理论的正确性。CAP理论告诉我们，一个分布式系统不可能满足一致性，可用性和分区容错性这三个需求，最多只能同时满足两个。
熊掌与鱼不可兼得也。关注的是一致性，那么您就需要处理因为系统不可用而导致的写操作失败的情况，而如果您关注的是可用性，那么您应该知道系统的read操作可能不能精确的读取到write操作写入的最新值。因此系统的关注点不同，相应的采用的策略也是不一样的，只有真正的理解了系统的需求，才有可能利用好CAP理论。


作为架构师，一般有两个方向来利用CAP理论


key-value存储，如Amaze Dynamo等，可根据CAP三原则灵活选择不同倾向的数据库产品。
领域模型 + 分布式缓存 + 存储 （Qi4j和NoSql运动），可根据CAP三原则结合自己项目定制灵活的分布式方案，难度高。

我准备提供第三种方案：实现可以配置CAP的数据库，动态调配CAP。




CA：传统关系数据库
AP：key-value数据库


而对大型网站，可用性与分区容忍性优先级要高于数据一致性，一般会尽量朝着 A、P 的方向设计，然后通过其它手段保证对于一致性的商务需求。架构设计师不要精力浪费在如何设计能满足三者的完美分布式系统，而是应该进行取舍。
不同数据对于一致性的要求是不同的。举例来讲，用户评论对不一致是不敏感的，可以容忍相对较长时间的不一致，这种不一致并不会影响交易和用户体验。而产品价格数据则是非常敏感的，通常不能容忍超过10秒的价格不一致。
CAP理论的证明：Brewer&#8217;s [...]]]></description>
		<wfw:commentRss>http://www.procty.com/?feed=rss2&amp;p=158</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>key-value分布式存储系统 备忘</title>
		<link>http://www.procty.com/?p=151</link>
		<comments>http://www.procty.com/?p=151#comments</comments>
		<pubDate>Sat, 15 May 2010 03:20:35 +0000</pubDate>
		<dc:creator>普罗</dc:creator>
				<category><![CDATA[数据存储]]></category>

		<guid isPermaLink="false">http://www.procty.com/?p=151</guid>
		<description><![CDATA[1、Hypertable：它是搜索引擎公司Zvents根据Google的9位研究人员在2006年发表的一篇论文《Bigtable：结构化数据的分布存储系统》开发的一款开源分布式数据储存系统。Hypertable是按照1000节点比例设计，以 C++撰写，可架在 HDFS 和 KFS 上。尽管还在初期阶段，但已有不错的效能：写入 28M 列的资料，各节点写入速率可达7MB/s，读取速率可达 1M cells/s。Hypertable目前一直没有太多高负载和大存储的应用实例，但是最近，Hypertable项目得到了百度的赞助支持，相信其会有更好的发展，地址：http://www.bt285.cn 下载。
2、Tokyo Tyrant：它是日本最大的SNS社交网站mixi.jp开发的 Tokyo Cabinet key-value数据库网络接口。它拥有Memcached兼容协议，也可以通过HTTP协议进行数据交换。对任何原有Memcached客户端来讲，可以将Tokyo Tyrant看成是一个Memcached，但是，它的数据是可以持久存储的。Tokyo Tyrant 具有故障转移、日志文件体积小、大数据量下表现出色等优势，详见：http://www.bt285.cn/aidesefang/
Tokyo Cabinet 2009年1月18日发布的新版本（Version 1.4.0）已经实现 Table Database，将key-value数据库又扩展了一步，有了MySQL等关系型数据库的表和字段的概念，相信不久的将来，Tokyo Tyrant 也将支持这一功能。值得期待。详见：http://www.bt285.cn/sejishikong/

3、CouchDB：它是Apache社区基于 Erlang/OTP 构建的高性能、分布式容错非关系型数据库系统（NRDBMS）。它充分利用 Erlang 本身所提供的高并发、分布式容错基础平台，并且参考 Lotus Notes 数据库实现，采用简单的文档数据类型（document-oriented）。在其内部，文档数据均以 JSON 格式存储。对外，则通过基于 HTTP 的 REST 协议实现接口，可以用十几种语言进行自由操作。

4、MemcacheDB：它是新浪互动社区事业部为在Memcached基础上，增加Berkeley DB存储层而开发一款支持高并发的分布式持久存储系统，对任何原有Memcached客户端来讲，它仍旧是个Memcached，但是，它的数据是可以持久存储的。

分布式存储系统Cassandra
从新闻 Twitter用户暴增20倍 计划弃用MySQL中看到了Cassandra数据库，网上查了一下这个Cassandra的资料，找到一篇较详细的中文资料：
Cassandra数据模型
下面一段引自这篇文章：
各种NoSQL数据库有很多，我最关注的还是BigTable类型，因为它是一个高可用可扩展的分布式计算平台，用来处理海量的结构化数据，而数据库同样也是处理结构化数据，所以除了没有SQL，在数据模型方面有相似之处。Cassandra是facebook开源出来的一个版本，可以认为是BigTable的一个开源版本，目前twitter和digg.com在使用。我们尝试从DBA的角度出发去理解Cassandra的数据模型。
NoSQL并不能简单的理解为No SQL，其本质应该是No Relational，也就是说它不是基于关系型的理论基础，而我们所有传统的数据库都是基于这套理论而发展起来的，所以SQL并不是问题的关键所在，比如有些NoSQL数据库可以提供SQL类型的接口，允许你通过类SQL的语法去访问数据。而Friendfeed则是反其道而行之，利用关系型数据库MySQL，采用了去关系化的设计方法，去实现自己的KeyValue存储。所以NoSQL的本质是No Relational。
在园子里发现老赵同志也在研究No SQL：MongoDB与Tokyo Tyrant性能比较（1）：基础CRU操作，从这篇文章回复中发现Inrie也在做相应的数据库选型，其中也提到了Cassandra，说实在的，之前基本没有关注过No SQL，看来这个相当热门和普遍的技术，非常有必要多多了解，只可惜这些产品多为xUnix上的，没有Windows上的，没有啥环境来学习一下，有空把Linux环境搭起来。
这里有位老兄写了个.Net Developer&#8217;s Guide to Getting Started with Cassandra Cassandra带有.NET平台下的驱动程序，非常的适合我等.NET之辈开始学习。
项目主页： http://incubator.apache.org/cassandra/
文档地址： http://wiki.apache.org/cassandra/GettingStarted

MongoDB入门简介（转：blog.csdn.net/lolinzhang/archive/2009/07/16/4353699.aspx）
有关于MongoDB的资料现在较少，且大多为英文网站，以上内容大多由笔者翻译自官网，请翻译或理解错误之处请指证。之后笔者会继续关注MongoDB，并翻译“Developer Zone”和“Admin [...]]]></description>
		<wfw:commentRss>http://www.procty.com/?feed=rss2&amp;p=151</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>厚黑之我见</title>
		<link>http://www.procty.com/?p=148</link>
		<comments>http://www.procty.com/?p=148#comments</comments>
		<pubDate>Thu, 01 Apr 2010 06:02:08 +0000</pubDate>
		<dc:creator>普罗</dc:creator>
				<category><![CDATA[未分类]]></category>

		<guid isPermaLink="false">http://www.procty.com/?p=148</guid>
		<description><![CDATA[见鬼，我居然买了一本厚黑学，并且还看了几章。
一直觉得自己老实巴交，和熊猫合计了一下买了本厚黑学，然后就和那边易经一样搁置在案头，忽然有天无聊拿起厚黑学看了两篇。
从字面上理解厚黑是脸皮厚，手段黑。书上的解释也是差不多这种意思。都是真是这种解释么？我一想，不对啊，这种厚真的那么有用么？比如一什么都不会的乞丐，他到盛大去应聘ceo，他对人事说：“嘿，哥们，你们不给我这个位子我就不走了。”结果会如何呢？要么被轰走，要么被抓走。
那么厚黑，改怎么理解呢？这里要感谢一下起点作者 梦入神机，他在《阳神》里面提到了积累，而且也让读者感受到什么是积累。我一想这个厚黑的厚为什么不能是厚积薄发的厚呢？
厚黑厚黑，先厚在黑，先要知道自己厚在哪里，在哪个方面有厚厚的积累，然后才能在厚的基础上行使黑这种手段。
厚，也可以理解为一种优势，举个例子，70码，这个事件里面充满了厚黑，厚是什么，一个是权力，一个是金钱。如果是个普通事件，那其一足够。可这是个对这个社会都有影响到事件，那么就要尽最大可能的来增加自己的厚方可平息事件。好了，如果厚足够了，那么就能行使黑了。赔偿，舆论，改封的封，该改的改，从最核心的权钱这两项积累中增加其他积累，然后行使手段，一个本该偿命的事件就很和谐的解决了。
如果是我等屁民，我们能搞定这种事么？我们可没有这种积累。
厚黑，先是积累，然后才是厚脸皮，黑心肝。
]]></description>
		<wfw:commentRss>http://www.procty.com/?feed=rss2&amp;p=148</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>24号AS聚会所得。</title>
		<link>http://www.procty.com/?p=141</link>
		<comments>http://www.procty.com/?p=141#comments</comments>
		<pubDate>Wed, 27 Jan 2010 08:30:53 +0000</pubDate>
		<dc:creator>普罗</dc:creator>
				<category><![CDATA[AS3]]></category>
		<category><![CDATA[生活]]></category>

		<guid isPermaLink="false">http://www.procty.com/?p=141</guid>
		<description><![CDATA[一个web游戏的产业链中有两条重要的链：
利益链、信息链。
利益链：
游戏除了休闲，还有一个重要的作用是为现实生活中不得志的人提供心理补偿的地方。这是利益链的一个重要驱动，游戏为玩家提供物品道具来弥补玩家在现实中办不到的事。
信息链：
游戏要维持利益链的持续，需要不断的给游戏添加内容，有个很好的办法就是为玩家提供参与游戏的机会。
游戏社会：
游戏社会是人与人的关系，包括对抗、竞争、合作。这三中关系牵扯到游戏的设计及玩法，同时游戏是否好玩也在其中。
对抗，在现在的游戏中普遍都能做到对抗。
竞争，包括个体与系统的竞争，个体与个体的竞争，个体与团队，团队与团队的竞争。
合作，一个团体的合作，如工会，宗族，联盟之类的。
这些关系其实都是现实生活中的一种映射，要让游戏设计的好玩，可以参照现实生活，加以发掘。
web游戏有个很重要的一点就是需要避免老帐号和新帐号的差距。
这个课题一直被研究，不过没有完美的解决方案，但有利的想法还是有的。
使用道具来减少新老帐号的差距。如建筑时常缩短的道具，如购买资源等等。
小号政策，即鼓励小号，非付费玩家可以通过建立小号来增强自身实力，当然，小号的聚集还是无法打败付费玩家的，而小号政策的最终目的就是让付费玩家能够有对抗的对象。 打吧，打吧，爽了就好。
消费行为：
从盛大纵横天下运营来的经验。
在游戏开始初期：玩家会大量购买资源道具，目的为了及早的超于其他玩家。
游戏中期：游戏的初期新手保护过期以后的时间，玩家会大量购买战争有关的道具，游戏全面战争开始了。
游戏后期：战争完成后，是大力发展团队的时期，这时，社会交流性的道具将是重点。
互动：
游戏少不了的是互动，有主动的，有被动的，在线的，离线的。
参照现实，可以有各种不同的互动设计。
游戏的发展有一个很有利的开始方法。即让工会入住，通常这只有大公司才能拥有这种资源。
socialgame：
社区游戏是交往习惯的社会应用，既要满足单人的交互，也要满足多人的交互。如单人游戏，联机游戏。
体验产生收费。任何的付费都是因体验而产生的。这一点需要好好的考量下。
]]></description>
		<wfw:commentRss>http://www.procty.com/?feed=rss2&amp;p=141</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
	</channel>
</rss>
