转一篇架构师间的问答------如何对应大数据量网站的考验收藏.doc

转一篇架构师间的问答------如何对应大数据量网站的考验 收藏 提问嘉宾： 林昊，网名BlueDavy，China OSGi User Group Director，淘宝网平台架构部架构师，个人的研究方向主要为Java模块化、动态化系统的构建以及高性能的大型分布式Java系统的构建。曾编写《OSGi实战》和《OSGi进阶》两篇Opendoc，为OSGi在中国的推广起到了很大的作用。 回答嘉宾： 黄冬，有多年软件开发、系统架构、系统运营的经验验。长期关注于高可用性、高可扩展性的系统架构设计。主持设计和运行过多个大型高容量产品和系统，也是中国 FreeBSD、Python社区的发起者和积极参与者，也是国内啄木鸟（）社区的创始人之一。现在正在北京从事系统架构咨询及系统运营外包的的创业之路。 林昊：随着数据量的不断增长以及前端应用的不断水平扩充，数据库的压力会成为明显的问题，这个时候常用的方案是数据拆分，在数据拆分时有些什么较好的拆分方式，以及如何能够做到数据拆分后对已有程序不产生影响或产生很小的影响？ 黄冬：这个拆分以应用的特性为主，从业务的特性出发更为重要，不是一个技术层面的通用解决方案，一般来讲先会从业务自身分析，已经有人总结过数据库做拆分的几种方式： 1．按功能划分（垂直切分） 将不同功能相关的表放到不同的数据库中，这样做的好处是非常直观。但当某一部分的功能其数据量或性能要求超出了可控的范围，就需要继续对其进行深入的再切分。 2．按表中某一字段值的范围划分（水平切分） 当伴随着某一个表的数据量越来越大，以至于不能承受的时候，就需要对它进行进一步的切分。一种选择是根据key 的范围来做切分，譬如 ID 为 1-10000的放到A上，ID 为10000~20000的放到B。这样的扩展就是可预见的。另一种是根据某一字段值来划分，譬如根据用户名的首字母，如果是A-D，就属于A，E-H就属于B。这样做也存在不均衡性，当某个范围超出了单点所能承受的范围就需要继续切分。还有按日期切分等等。 3．基于hash的切分 类似于memcached的key hash 算法，一开始确定切分数据库的个数，通过hash取模来决定使用哪台。这种方法能够平均地来分配数据，但是伴随着数据量的增大，需要进 行扩展的时候，这种方式无法做到在线扩容。每增加节点的时候，就需要对hash 算法重新运算，数据需要重新割接。 4．基于路由表的切分 前面的几种方式都是根据应用的数据来决定操作的，基于路由表的切分是一种更加松散的方法。它单独维护一张路由表，根据用户的某一属性来查找路由表决定使用哪个数据库，这种方式是一种更加通用的方案。因为每次数据操作的时候都需要进行路由的查找，所以将这些内容存储到一台独立的Cache上是一个非常好的方式，譬如memcached。这种切分的方式同时也带来了另一个好处，当需要增加数据库节点的时候，可以在不影响在线应用的情况下来执行，当然这也跟应用 程序的架构设计相关，你的设计必须适用这种增加。 最后我还需要说明的是数据不止可以存在数据库中，大的概念来讲，像邮件系统中的邮件、视频文件等都有着相同的分布式存储的算法。我自己经历过的邮件、播客等都应用了大量的数据切分的模式将数据切分到数百台存储节点中去。 林昊：数据拆分只是解决数据量增长后带来的问题的一种解决方案，请问是否还有一些其他的方式来解决数据量增长带来的问题呢，以及如何来实现这些方式呢？ 黄冬： 原则上来讲只有两种方法来解决数据增长带来的问题：拆分和增容。也就是拆到多个节点去，或是提升单个节点的容量能力。但是也有一些特别的方式，它们不通用，需要从业务关点来仔细评估： 1．Cache 是一种应用已久的方案，通过提前计算，将数据缓存起来。传统新闻网站的新闻的分发、Cache应用已久，而且当动态计算无法支撑时，静态化、缓存化总是百试不爽的终级方案。 2．阶段计算、阶段存储，通过阶段的计算，减少最终数据量。例如mrtg（一种通用的snmp监控程序）它的rrd 存储就是这样阶段计算、阶段存储的例子，最终使用的24小时数据、月/ 年数据总是最少的，不一定需要所有的详细数据。 林昊：互联网应用的功能都是出于一种高速发展的状况，如果所有功能都在同一个系统上的话，会带来维护困难、机器性能无法合理发挥以及水平扩展性不够好等问题，对于此类问题应如何解决，解决时带来些什么技术挑战呢？ 黄冬：互联网的应用已经将IT 行业自身与其他行业的结合融合了起来。从前的系统运营、业务运营、软件开发甚至硬件开发等结合到了一起。最为核心的是将外包服务者和技术服务提供者融合了起来。未来将是服务为王的时代，所以这个时代给技术带来的挑战皆因从服务提供到运营提供带来的转变： 1）软件开发如何从软件工