-
个人简介:
PHP开发者,高可用性、分布式集群实践者,伪Python、GAE开发者,伪Linux系统管理员,伪MySQL管理员
2009年8月至今服务于阿里巴巴云计算公司
2008年8月至2009年7月31日服务于博客大巴
-
归档
- 2012 年一月
- 2011 年十一月
- 2011 年九月
- 2011 年八月
- 2011 年七月
- 2011 年六月
- 2011 年五月
- 2011 年三月
- 2011 年二月
- 2011 年一月
- 2010 年十二月
- 2010 年十一月
- 2010 年十月
- 2010 年九月
- 2010 年八月
- 2010 年七月
- 2010 年六月
- 2010 年五月
- 2010 年四月
- 2010 年三月
- 2010 年二月
- 2010 年一月
- 2009 年十二月
- 2009 年十一月
- 2009 年十月
- 2009 年九月
- 2009 年八月
- 2009 年七月
- 2009 年六月
- 2009 年五月
- 2009 年四月
- 2009 年三月
- 2009 年二月
- 2009 年一月
- 2008 年十二月
- 2008 年十一月
- 2008 年十月
- 2008 年九月
- 2008 年八月
- 2008 年七月
- 2008 年六月
- 2008 年五月
- 2008 年四月
- 2008 年三月
- 2008 年二月
- 2008 年一月
- 2007 年十二月
- 2007 年十一月
- 2007 年四月
-
杂项
标签归档:应用架构
淘宝在数据处理领域的项目及开源产品介绍
淘宝在数据存储和处理领域在国内互联网公司中一直保持比较靠前的位置,而且由于电子商务领域独特的应用场景,淘宝在数据实时性和大规模计算及挖掘方面一直在国内保持着领先,因此积累了很多的实践的经验和产品。 TimeTunnel 基于Hbase打造的消息中间件,具有高可靠、消息顺序、事务等传统特性,还能按时间维度反复订阅最近历史的任意数据 高性能的broker,单节点达2万TPS,实际支持上千长链接并发 承载海量的数据传输,日同步数据达10TB,并且包含淘宝主营收入等关键性数据 在各IDC内,部署了超过2000个客户端,覆盖全网日志传输 Scribe、flume、activemq、ZeroMQ?我们可以做得更强大 TBFS 基于Hdfs 0.20进行全面改造,设计目标:单个集群可达10000台服务器,支持10亿文件、100PB的数据的存储 领先于社区的全新设计,彻底解决namenode单点问题,并可实现集群在线升级 期待你来挑战:snapshot、异地数据复制、多级的cache、软硬链接支持 Hbase 基于Hbase0.90.3进行改造,目前有上百台的Hbase服务器,支淘宝7个online应用,online数据存储达100T 支持本地化数据计算、二级引索 期待你来挑战:无阻塞的compact、更多的事务支持、更短的请求响应时间、更强大的索引(Lucene for hbase) Mapreduce 基于Hadoop0.19改造,最大单个集群规模达2000台服务器,兼容hadoop0.20 绝大多数API 实际存储数据超过10PB,日运行mapreduce job达5万个 期待你来挑战:更高效任务调度、更优雅的计算资源管理、更灵活的分布计算模型 Hive 基于hive0.6改造,修改的patch达上百个,支持SQL中间结果复用等众多特性 支持淘宝几乎所有的商业数据分析任务,是各行业数据分析师和数据开发工程师必备的技能 期待你来挑战:Hive & Pig能混合编程?现在不能,你敢想就可以来做! Taobao-pamirs-schedule taobao-pamirs- schedule是一个基于分布式环境的多线程任务处理框架。目的是让一种批量任务或者不断变化的任务,能够被动态的分配到多个主机的JVM,不同的线程组中并执行。所有的任务能够被不重复,不遗漏的快速处理。它将需要执行的任务抽象成一致的任务模型,进行统一的管理和监控。运用schedule,任务能够比较均匀的分发到多台机器上进行处理,并且可以动态的进行水平扩展。 QLExpress 一个轻量级的脚本引擎,作为一个嵌入式规则引擎在业务系统中使用。让业务规则定义简便而不失灵活。让业务人员就可以定义业务规则。 支持标准的JAVA语法,还可以支持自定义操作符号、操作符号重载、函数定义、宏定义、数据延迟加载等。 UIC Uic是个海量数据的高稳定高并发高响应高可靠高一致性的系统。海量数据:现在整个用户中心的注册用户数接近6亿,加上地址,支付宝绑定数据,接近20亿。现在通过分库分表存在了16个库1024张表里面。高稳定,高可靠:用户中心是淘宝最为核心的系统之一,一个完整的交易流程需要访问UIC高达几十次,所以UIC的稳定是整个淘宝的重中之重,我们为了UIC的稳定做了很多容灾的方案,包括多机房的备份,缓存的容灾,mysql的容灾,流量的控制等等,可以说UIC的核心就是各种容灾体系和在各种极端情况的下解决措施高并发,高响应:每天访问UIC的数据在200亿左右,我们使用了tair做为缓存,使用protobuf序列化, 尽可能的提高缓存的命中率,现在用户数据的命中率在99%。 … 继续阅读
软件构建中的理想设计特征
1、最小复杂度。设计的手艺好目标就是要复杂度最小,避免作出“聪明的”设计,因为“聪明的”设计常常难以理解 2、易于维护。 易于维护意味着在设计时为做维护的程序员着想。 3、松散耦合。松散耦合意味着在设计时让程序各个组织称部分之间的管理关系最小。通过应用类接口中合理还凑向、封装及信息隐藏等原则设计出相互关联尽可能小的类。减少关联也就是减少了集成、测试和维护时的工作量。 3、可扩展性。可扩展性是只可以增强系统功能而无须改变底层结构,可以改变某一个方面功能而不影响其他部分。 4、可重用性。可重用意味着代码可以在其他系统的组成部分中重复使用,降低整体的成本和提高生产效率。 5、高扇入。高扇入就是说让大量的类是有那个某个给定的类。这就是意味着设计出的系统很好的利用较低层次上的工具类。 6、低扇出。低扇出就是让一个类里少量或者适中的使用其他的类。高扇出说明了一个类使用了大量其他的类,因此可能变得过于复杂。 7、可移植性。可移植性是说应该设计的系统很方便的移植到其他的环境中。 8、精简性。精简就意味着系统没有多余的部分。这样有利于后面的单元测试。 9、层次性。层次性就意味着尽量保持系统各个层次保持可分解,使你能在任何层面观察系统。 10、标准技术。一个系统所依赖的外来的,古怪的东西越多,别人在第一次想要理解它的时候就越头痛。尽量使用标准化,常用的方法,让整个系统给人一种熟悉的感觉。
会话状态模式
个人觉得会话状态模式其实算不得一种模式,因为无非就两种,而且必须是其中的一种,一种存放在客户端,一种存放在服务端。两者都有风险和优点。 通常将会话保存在客户端是为了获得服务端的高度无状态特性,即服务端可以做到完全的无状态。Java中通常使用传输对象来进行数据传输,因为传输对象可以在网上进行序列化,即使是很复杂的数据也可以进行传输。当然序列化是有风险和代价的,不是所有的序列化数据都能够被反序列化回来,虽然出现反序列化回来的出错的概率很小。 如果使用HTML的话,选择相对多一点,URL参数,隐藏表单域和Cookie,URL对于较小数据量还是比较容易使用的,现代浏览放开了对URL长度的限制,但我们不得不考虑一些古董用户的需求,毕竟IE6及以下版本的浏览器还主导着WEB世界,而且URL过长,也不符合REST原则,更不美观。 隐藏表单域适合于POST方式的请求,POST方式可以避免因浏览器限制URL长度而导致的被截断的问题。隐藏表单域在我曾经的代码中经常使用,主要是为了跟踪和referer的referer,也就是跳转到一个页面之前的原来页面。 Cookie方式是最优争议的一种方式,PHPWind采用了这一种方法,从开发者口中得知,是为了减少服务器的负载,因为服务器不用维护session状态。通过把数据序列化或者加密后以文本方式放到Cookie中,我没有测试过,PHPWind这样做是不是真的能降低服务器的负载,根据我以前的测试,session维护成本对于服务器的影响是微乎其微的,还不如优化一条SQL来得更痛快,更有效,而且放在Cookie中会导致用户请求的流量变大,在很多上下带宽不对称的机房中,这是个严重的问题,比如blogbus之前存放在上海的**机房就是这样。而且为了获得Cookie中的数据还需要进行一些列运算,未必比维护session的成本小,而且会导致严重的安全问题。只要算法是可逆的,就一定能被人破解,何况我等庸人搞的算法。 服务器会话状态最简单的一种就是把会话数据放到应用服务器的内存中,可以将会话数据以会话标识号作为键标识放到内存映射表中,现在很多工具可以做到,比如memcache等key-value 的内存存储工具。 另一种是持久化,持久化也可以分为两种,一种以二进制序列化形式存放,但这样做的缺点是不容易阅读,更新起来成本有点高,如果每个会话都一个文件的话,在高并发的时候还得解决文件系统的巨量小文件查找效率问题。还有一种就是持久化到数据库,这个存放会话的模式,可能会因为维护会话状态而带来巨大的数据库开销问题,而且为了及时清除过期的会话,往往配合触发器来进行。 总结起来每种会话管理都有天生的缺陷,如果能多种结合能够提升一些效率,比如内存缓存配合持久化数据库,就是眼下很多高负载网站正在使用的模式,也许还有其他的更多的模式和方法有待探寻~~
数据源架构模式笔记(一)
数据源架构模式笔记 一、表数据入口 表数据入口半酣了用于访问单个表的或视图的所有SQL,如CRUD操作,其他代码调用它的方法来实现所有与数据库的交互。 表数据入口很简单,一般包括几个从数据库中干活去数据的查找方法以及更新删除放放风每个方法都将输入参数映射为一个SQL调用并在数据库链接上执行改语句。由于表数据入口用于数据读写,所以通常是无状态的。 使用时机: 1、可以和表模块一起很好的使用,它称身隔一个记录集数据结构由表模块处理。 2、特别适用于事务脚本。 3、通常表数据入口和领域模型很少一起使用,因为数据映射器更好地分离了领域模型和数据库。 二、行数据入口 行数据入口充当数据源中单条记录入口的对象,每行一个实例。行数据入口和单条记录机器相似的对象,如数据库中的一行。在该对象中数据库中每一列变成了一个域。行数据入口一般能实现从数据源类型到内存中类型的任意转换,这种转换很简单。这个模式保持一行中的数据以便客户可以直接访问行数据入口,行数据入口是每一个数据行的良好接口。这种方法尤其适用于事务脚本。 使用行数据入口通常非为两步:第一步是否真的需要用入口;第二步,是使用行数据入口还是表数据入口。 行数据入口能和数据映射其一起配合使用,尽管这样看起来有点多此一举,当行数据入口从元数据自动生成,而数据映射器由手动实现时,这种方法会很有效。 如果把事务脚本和行数据入口一起使用,可能会发现业务逻辑在多处脚本中重复出现,这些逻辑可能在行数据入口中有族谱那个,不断移动这些逻辑会使行数据入口演变成活动记录,活动记录很好,因为他减少了业务逻辑中的重复。
《企业应用架构模式》笔记一
企业应用 定义: 企业应用一般都涉及到持久化数据。 企业应用一般都涉及大量数据 企业应用还涉及很多人同时访问 企业应用还涉及大量操作数据的用户界面屏幕。 企业应用很少独立存在,通常需要与散布在企业周围的其他企业应用集成。(技术多样化,协议多样化) 可伸缩性: 响应时间 响应性 等待时间 吞吐率 负载 负载敏度 效率 领域逻辑组织方式: 1.事务脚本 2.领域模型 3.表模块 服务层: 表现逻辑和领域逻辑之间的交互完全通过服务层,就像应用程序API一样。 如果确实需要,使用最小化的服务层 映射到关系数据库: 1. 为查询语句返回的每一行产生一个它的实例,种种行数据入口就行是面向对象方式来看待数据。 2.许多环境提供记录集,这种表和数据行的一种通用数据结构,用来模拟数据库的表格属性。 如果使用记录集,对于数据库的每个表只需要一个对象来管理。 并发: 解决方案有两个,一个是隔离,一个是不变性 隔离是学习操作系统分配内存的方式,让一个单元只允许一个进程访问 只有共享数据可以被修改的情况下并发问题才会出现。 事务属性: 1.原子性 在事务里面所有的动作要么全部完成,要么全部回滚 2.一致性 在事务开始和结束的时候,所有的资源要保持一致 3.隔离性 在事务完成之后,他的结果对于其他事务才是可见的 4.持久性 已提交的事务必须是可持久性的,即任何崩溃都是可以保存下来的 … 继续阅读