- 浏览: 223968 次
- 性别:
- 来自: 成都
文章分类
- 全部博客 (213)
- SQLServer (8)
- flex (8)
- 文章 (5)
- java (91)
- 数据结构 (0)
- 设计模式 (0)
- C# (2)
- Oracle (4)
- 技术 (4)
- 云计算 (0)
- 算法 (0)
- 记录 (3)
- javascript (5)
- div/css (1)
- http (0)
- IE (1)
- web (1)
- hadoop (0)
- extjs (4)
- hibernate (6)
- 错误记录 (5)
- mysql (4)
- json (1)
- jvm (1)
- spring (4)
- 工具 (2)
- tomcat (3)
- cxf (3)
- spring data (1)
- memcached (5)
- android-exception (2)
- 数据压缩 (1)
- 博客 (2)
- bat (0)
- nginx (3)
- svn (2)
- jpa (1)
- windows (2)
- h2 (2)
- webservice (2)
- android (5)
- oa (0)
- eclipse (2)
- jquery (2)
- jni (4)
- weblogic (1)
- work (0)
- smartclient (1)
- sql (0)
- excel (0)
- test (0)
- t (0)
- js (4)
- utils (0)
- bootstrap (0)
- sniper (0)
- ztree (0)
- google (0)
- mdb (0)
- redis (1)
- 思想 (1)
- css (0)
- appCan (0)
- activiti (0)
- 工作 (0)
- 浏览器 (1)
本文只是做个简介,起抛砖引玉效果,希望能给大家一些启发(ps:作为一线码农,在工作中经常接触并使用这些框架,深深为其强大功能、设计思路所折服)
1. session框架
session大家肯定都不陌生,由于HTTP协议本身是无状态,前后两次请求通常是没有关联的,但由于一些业务需求,又必须让其有所关联(比如登录,不可能让用户每次访问一个页面都需要重新登录一次,那用户肯定会疯掉)
此时我们就需要借助session机制,将用户的一些信息存储在服务端,其主键jsessionid存储于客户端的cookie中,下一次用户发起请求时,servlet框架会根据jsessionid自动寻找关联的信息。
但随着互联网的快速发展,用户群越来越大,如何来存储、管理庞大的session信息显得越来越重要。
通常的作法是采用集群(多么熟悉的名词,ho~ho~),例如tomcat采用集群节点广播复制,jboss采用配对复制,但都严重影响系统的伸缩性,不能通过增加机器达到更好的水平伸缩,而且随着节点的增加,节点间的通信也更加频繁,势必会造成系统内耗加大。
webX框架的基于cookie的session可以有效的解决这个问题,将信息存于客户端浏览器的cookie中,而应用节点本身不保存任何状态信息。但要注意的一点是不同的浏览器对cookie的支持标准不一样,关于这块可参照之前的文章《浅谈浏览器cookie》。对于这个问题,我们的解决方案是“多值cookie”,一个组合键对应多个cookie值,可以有效将cookie的个数控制在20个以内,很大程度节省了cookie信息的存储空间,更多精彩可参考《Request context之session指南》
2. 缓存tair
缓存,主要是为了减轻对数据库的压力,使用场景非常广泛。有浏览器缓存、反向代理缓存、页面缓存、对象缓存等
tair是淘宝的一个高性能、分布式、可扩展、高可用性的key-value结构的存储系统。
非持久化:
mdb引擎: 只支持key/value,单机性能7w qps(测试条件:单条记录512字节,响应时间2ms内)
rdb引擎: 不仅支持key/value,还支持list/hashmap/set/sortedset等复杂数据结构。
持久化:
kdb引擎:采用了kyoto cabinet做为引擎,性能在2000 qps单台。
ldb引擎:采用了leveldb做为引擎,并且自带cache。服务器采用了ssd,性能在5w qps以上。
目前tair已经开源,开源地址:http://code.taobao.org/p/tair/src/
3. 服务化(HSF框架,dubbo)
服务化的核心就是解耦,将生产端和消费端有效拆分,借助于HSF来达成调用关联。使用系统的整体可用性、扩展性大大增强。
举个很形象的例子,一个业务开创之初,可能只有一个应用,但随着业务的不断膨胀,代码量也越来越大,无论后期开发还是维护带来的成本都是很高的,此时,从架构的角度会进行系统拆分,通过增加子域名的形式,借助于http请求,将不同的业务交由不同的系统来处理。
比如商品展示交由系统A处理;当用户添写一个购买数量,并选择好规格属性后,点击“购买”按钮,会将请求发送到系统B来处理, 无论从业务划分、模块定位、还是代码开发,都鲜明不少。
现在回到我们服务化的内容来,在服务化推广之前,底层业务通常是这样处理,如果你想使用部门A的业务(通常要数据库操作),首先要引入相应的jar包,尤其是底层的dal层的包(sql.xml ,接口,接口实现等),然后在应用中手动配置各种bean关系,可以说相当繁琐。当然如果只是配置一次,再繁琐也忍了。互联网千变万化,电子商务更是瞬息万变,业务变更相当频繁,代码频繁改动那更是家常便饭。想象一下,如果你的dal层jar包被十几个业务线所依赖,如果你想改底层的dao接口实现,你是不是需要这十几个业务线也跟着空发布一次,只是为了打包时能加载你最新的代码。
痛苦之大难以想象。幸好有了服务化。服务化可以有效将业务收扰到服务端,对外只暴露一个接口即可,如果你想用我的业务,只需做下简单接口配置即可,调用时,HSF框架会帮你找到对应的服务端,然后服务端会进行相应的业务处理,返回给你想要的结果,是不是清晰了很多。
dubbo已开源,地址:http://code.alibabatech.com/wiki/display/dubbo/Home
4. 数据库拆分TDDL
现在是大数据时代,随便一个应用,动辄就是上千万的数据,数据库表示压力越来越大。分库分表成为业务发展的不二选择。
TDDL是淘宝开发的一套分布式数据库访问引擎。可以有效解决
a)数据访问路由:数据的读写请求发送到最合适的地方
b)数据的多向非对称复制:一次写入,多点读取
c)数据的存储自由扩展:不再受限于单台机器的容量瓶颈和速度瓶颈,平滑迁移
关于分库分表可以看看iteye上的一篇文章《淘宝下单高并发解决方案》
另外tddl也开源了,开源地址:http://code.taobao.org/p/tddl-dynamic-datasource/src/trunk/
5. 异步消息(notify)
主要是借助消息中间件,采用异步通信来达到系统的伸缩性,以最大化的对各个子系统解耦。
具体是采用同步通信还异步通信,需要结合业务来衡量,如果业务本身关联度较大,建议还是采用同步通信比较靠谱。
关于异步消息这块,之前有过简单整理《基于消息的分布式架构设计》
6. 非结构化数据存储 ( TFS,NOSQL)
并非所有的数据都是结构化的,比如一些配置文件,交易的快照等,一般不适合保存到RDBMS,更符合一种Key-value的结构;另一类数据,数据量非常大,但实时性要求不高,此时这些数据也需要通过另外的一种存储方式进行存储。
一些静态文件,比如各个商品的图片,商品描述等信息,这些信息因为比较大,放入RDBMS会引起读取性能问题,影响其它数据读取性能,也要和其它信息分开存储,一般的选择分布式文件系统。
随着互联网的发展,08年下半年开始逐渐流行了一个概念就是NOSQL。我们都知道根据CAP理论,一致性,可用性和分区容错性三者不能同时满足,最多只能同时满足两个。
传统关系数据库采用ACID事务策略,更加讲究高一致性而降低了可用性的需求;但互联网应用往往对可用性的要求要略高于一致性的需求,这时候就要避免采用数据的ACID事务策略,转而采用BASE(基本可用性,事务软状态以及最终一致性)事务策略
目前此类产品有facebook 的cassandra,apache hbase,google bigtable等,非常适合一些非结构化的数据,如key-value形式数据存储,具有很好的水平伸缩性
1. session框架
session大家肯定都不陌生,由于HTTP协议本身是无状态,前后两次请求通常是没有关联的,但由于一些业务需求,又必须让其有所关联(比如登录,不可能让用户每次访问一个页面都需要重新登录一次,那用户肯定会疯掉)
此时我们就需要借助session机制,将用户的一些信息存储在服务端,其主键jsessionid存储于客户端的cookie中,下一次用户发起请求时,servlet框架会根据jsessionid自动寻找关联的信息。
但随着互联网的快速发展,用户群越来越大,如何来存储、管理庞大的session信息显得越来越重要。
通常的作法是采用集群(多么熟悉的名词,ho~ho~),例如tomcat采用集群节点广播复制,jboss采用配对复制,但都严重影响系统的伸缩性,不能通过增加机器达到更好的水平伸缩,而且随着节点的增加,节点间的通信也更加频繁,势必会造成系统内耗加大。
webX框架的基于cookie的session可以有效的解决这个问题,将信息存于客户端浏览器的cookie中,而应用节点本身不保存任何状态信息。但要注意的一点是不同的浏览器对cookie的支持标准不一样,关于这块可参照之前的文章《浅谈浏览器cookie》。对于这个问题,我们的解决方案是“多值cookie”,一个组合键对应多个cookie值,可以有效将cookie的个数控制在20个以内,很大程度节省了cookie信息的存储空间,更多精彩可参考《Request context之session指南》
2. 缓存tair
缓存,主要是为了减轻对数据库的压力,使用场景非常广泛。有浏览器缓存、反向代理缓存、页面缓存、对象缓存等
tair是淘宝的一个高性能、分布式、可扩展、高可用性的key-value结构的存储系统。
非持久化:
mdb引擎: 只支持key/value,单机性能7w qps(测试条件:单条记录512字节,响应时间2ms内)
rdb引擎: 不仅支持key/value,还支持list/hashmap/set/sortedset等复杂数据结构。
持久化:
kdb引擎:采用了kyoto cabinet做为引擎,性能在2000 qps单台。
ldb引擎:采用了leveldb做为引擎,并且自带cache。服务器采用了ssd,性能在5w qps以上。
目前tair已经开源,开源地址:http://code.taobao.org/p/tair/src/
3. 服务化(HSF框架,dubbo)
服务化的核心就是解耦,将生产端和消费端有效拆分,借助于HSF来达成调用关联。使用系统的整体可用性、扩展性大大增强。
举个很形象的例子,一个业务开创之初,可能只有一个应用,但随着业务的不断膨胀,代码量也越来越大,无论后期开发还是维护带来的成本都是很高的,此时,从架构的角度会进行系统拆分,通过增加子域名的形式,借助于http请求,将不同的业务交由不同的系统来处理。
比如商品展示交由系统A处理;当用户添写一个购买数量,并选择好规格属性后,点击“购买”按钮,会将请求发送到系统B来处理, 无论从业务划分、模块定位、还是代码开发,都鲜明不少。
现在回到我们服务化的内容来,在服务化推广之前,底层业务通常是这样处理,如果你想使用部门A的业务(通常要数据库操作),首先要引入相应的jar包,尤其是底层的dal层的包(sql.xml ,接口,接口实现等),然后在应用中手动配置各种bean关系,可以说相当繁琐。当然如果只是配置一次,再繁琐也忍了。互联网千变万化,电子商务更是瞬息万变,业务变更相当频繁,代码频繁改动那更是家常便饭。想象一下,如果你的dal层jar包被十几个业务线所依赖,如果你想改底层的dao接口实现,你是不是需要这十几个业务线也跟着空发布一次,只是为了打包时能加载你最新的代码。
痛苦之大难以想象。幸好有了服务化。服务化可以有效将业务收扰到服务端,对外只暴露一个接口即可,如果你想用我的业务,只需做下简单接口配置即可,调用时,HSF框架会帮你找到对应的服务端,然后服务端会进行相应的业务处理,返回给你想要的结果,是不是清晰了很多。
dubbo已开源,地址:http://code.alibabatech.com/wiki/display/dubbo/Home
4. 数据库拆分TDDL
现在是大数据时代,随便一个应用,动辄就是上千万的数据,数据库表示压力越来越大。分库分表成为业务发展的不二选择。
TDDL是淘宝开发的一套分布式数据库访问引擎。可以有效解决
a)数据访问路由:数据的读写请求发送到最合适的地方
b)数据的多向非对称复制:一次写入,多点读取
c)数据的存储自由扩展:不再受限于单台机器的容量瓶颈和速度瓶颈,平滑迁移
关于分库分表可以看看iteye上的一篇文章《淘宝下单高并发解决方案》
另外tddl也开源了,开源地址:http://code.taobao.org/p/tddl-dynamic-datasource/src/trunk/
5. 异步消息(notify)
主要是借助消息中间件,采用异步通信来达到系统的伸缩性,以最大化的对各个子系统解耦。
具体是采用同步通信还异步通信,需要结合业务来衡量,如果业务本身关联度较大,建议还是采用同步通信比较靠谱。
关于异步消息这块,之前有过简单整理《基于消息的分布式架构设计》
6. 非结构化数据存储 ( TFS,NOSQL)
并非所有的数据都是结构化的,比如一些配置文件,交易的快照等,一般不适合保存到RDBMS,更符合一种Key-value的结构;另一类数据,数据量非常大,但实时性要求不高,此时这些数据也需要通过另外的一种存储方式进行存储。
一些静态文件,比如各个商品的图片,商品描述等信息,这些信息因为比较大,放入RDBMS会引起读取性能问题,影响其它数据读取性能,也要和其它信息分开存储,一般的选择分布式文件系统。
随着互联网的发展,08年下半年开始逐渐流行了一个概念就是NOSQL。我们都知道根据CAP理论,一致性,可用性和分区容错性三者不能同时满足,最多只能同时满足两个。
传统关系数据库采用ACID事务策略,更加讲究高一致性而降低了可用性的需求;但互联网应用往往对可用性的要求要略高于一致性的需求,这时候就要避免采用数据的ACID事务策略,转而采用BASE(基本可用性,事务软状态以及最终一致性)事务策略
目前此类产品有facebook 的cassandra,apache hbase,google bigtable等,非常适合一些非结构化的数据,如key-value形式数据存储,具有很好的水平伸缩性
发表评论
-
adc-0205
2021-02-18 09:51 0data-handler-1.0-SNAPSHOT-B2-20 ... -
spring aop和ioc的区别
2017-06-21 15:25 0什么是DI机制? 依赖注入(Dependecy Inject ... -
SpringMVC的各种参数绑定方式
2017-06-16 09:39 0http://www.cnblogs.com/HD/p/410 ... -
spring mvc传递list参数
2017-06-15 23:41 1332http://www.cnblogs.com/liusongl ... -
eclipse字体问题
2017-06-09 12:26 544.metadata\.plugins\org.eclipse. ... -
泛型方法指定返回值类型
2017-04-01 17:11 1044public static <T> T getCa ... -
mysql数据库编码设置
2017-03-31 14:09 0SHOW VARIABLES LIKE 'char%' se ... -
java异常分类
2017-03-21 20:00 745http://www.blogjava.net/balajin ... -
Java工程师成神之路
2017-03-08 13:59 0http://www.importnew.com/17389. ... -
JEECG快速开发平台
2017-02-27 17:03 0http://demo.jeecg.org/loginCont ... -
Java性能调优笔记
2017-02-27 15:38 0http://www.cnblogs.com/likehua/ ... -
Windows环境Mycat数据库分库分表中间件部署
2017-02-27 14:23 0http://www.cnblogs.com/Wulex/p/ ... -
浅谈算法和数据结构(1):栈和队列
2017-02-27 14:21 0http://blog.jobbole.com/79267/ ... -
关系型数据的分布式处理系统MyCAT
2017-02-27 14:14 0http://www.blogjava.net/amigoxi ... -
关于Apache/Tomcat/JBOSS/Neginx/lighttpd/Jetty等一些常见服务器的区别比较和理解
2017-02-27 14:05 0http://blog.csdn.net/allenlinru ... -
实战 Lucene,第 1 部分: 初识 Lucene
2017-02-27 14:02 0https://www.ibm.com/developerwo ... -
内存调优
2017-02-27 09:20 382http://blog.csdn.net/gjanyanlig ... -
内存管理和垃圾回收
2017-02-27 09:14 618http://blog.csdn.net/gjanyanlig ... -
activiti学习 表相关
2017-02-22 10:53 0select * from EFLOW_WO_COMMON w ... -
jboss之启动加载过程详解(-)
2017-02-20 17:04 1020http://www.2cto.com/os/201404/2 ...
相关推荐
【淘宝网高性能可伸缩架构技术探秘】深入解析了如何构建高可用、可扩展的电商系统。在设计这样的架构时,几个关键点至关重要:应用无状态、有效使用缓存和应用拆分。 1. 应用无状态: 系统的伸缩性很大程度上依赖...
5. **高可用性设计**:淘宝架构注重故障容错和快速恢复,采用冗余备份、故障切换、服务降级等策略,确保在部分系统故障时仍能提供基本服务。 6. **安全机制**:淘宝的安全措施包括防火墙、DDoS防护、SQL注入防护、...
而在非Java领域,如C++用于高性能计算,Python用于数据分析和机器学习,也展现了淘宝网在技术创新上的广度与深度。 综上所述,淘宝网的开源架构是其成功的关键之一。通过精心选择并集成开源与商业技术,淘宝网构建...
"淘宝_高级系统架构设计师"这个主题涉及到的知识点非常广泛,涵盖了多个技术领域,包括但不限于分布式系统、微服务架构、高可用性设计、大数据处理、云计算以及性能优化等。以下将对这些关键知识点进行详细阐述。 ...
淘宝的软硬件架构设计旨在满足高容量、高性能的需求。硬件方面,采用了先进的网络拓扑结构和数据库结构;软件体系架构则注重容灾能力,确保在任何情况下都能维持正常的服务。 ### 四、系统约束 为了维护架构的稳定...
更进一步,淘宝可能采用了分库分表、分布式事务处理、缓存策略等多种技术来优化性能和提升稳定性。此外,还可能涉及到数据库的智能化运维和监控,以及如何应对大数据时代的挑战。 接下来,“互联网公司技术架构资料...
3. **高性能**:确保用户的操作能够迅速响应,提升用户体验。 4. **高可维护性**:便于技术团队进行维护和升级,降低运营成本。 #### 三、淘宝的业务特性 淘宝是一个交易网站,其业务特性决定了技术架构的设计方向...
淘宝技术架构的核心需求主要体现在四个方面:高稳定性、高容量、高性能以及高可维护性。 1. **高稳定性**:面对庞大的用户群体与交易量,任何系统宕机都将带来巨大的经济损失和信誉损失。 2. **高容量**:随着用户...
这个实例深入展示了如何构建一个可扩展、高并发、高性能的在线购物系统。下面将详细探讨其中涉及的知识点。 1. **分层架构**:淘宝的架构通常采用典型的三层或更多层次设计,包括表示层(用户界面)、业务逻辑层...
淘宝网站的演变,数据并发和产品群的管理,高可用性,以及开放性;以及到现在的系统化,专业化,智能化。淘宝一路走来,为我们趟了不少的雷,有时间的话,还是需要仔细研究一下系统架构的艺术,没有最好的架构,只有...
淘宝技术架构是指淘宝网站所采用的一系列计算机软件和硬件的技术解决方案和部署策略。这些架构和策略的设计与实施,是为了支持淘宝庞大的用户群体和复杂多变的在线交易需求。淘宝技术架构的核心部分包括其整体网络...
淘宝数据库架构演进历程及OceanBase架构PPT课件.pptx 本资源摘要信息涵盖淘宝数据库架构演进历程的三个阶段,包括早期单机式的 MySQL 使用方式、Mysql 迁移到 Oracle 并升级到小型机、高端存储,最后到异构数据库...
综上所述,淘宝数据库架构的演进历程展示了互联网公司在面对业务快速发展的挑战时,如何通过技术创新和架构优化,逐步解决性能、扩展性、数据一致性和高可用性等问题。在这个过程中,Java作为主要的开发语言,发挥了...
### 淘宝技术架构进化之路 #### 一、引言 随着互联网技术的迅猛发展,电子商务平台如淘宝等在用户量与业务复杂度上都经历了指数级的增长。因此,如何构建一个稳定、高效且可扩展的技术架构成为了一个至关重要的问题...
随着业务的增长和技术的发展,TFS也在不断地进行架构演进,以满足更高的性能、可靠性和扩展性的需求。 #### 二、TFS架构关键组件 TFS架构主要由以下几个关键组件构成: 1. **Master/NS(Name Server)**: 名称...
它以轻量级、高性能和高可用性为核心,解决了电商领域常见的并发控制、数据一致性等问题,为构建大规模分布式系统提供了有力的支持。了解和掌握FourInOne,有助于提升我们在分布式计算领域的专业素养,更好地应对...
- **高性能与高可用性**:采用负载均衡技术、多机房部署策略等手段,确保系统的高可用性和高性能。 #### 五、总结 淘宝网的系统架构发展历程,不仅反映了互联网技术的快速迭代,也展示了如何根据业务需求和技术发展...