昆明网页制作_网站制作套餐_赣州网站制作_天津 网站建设

1、一台服务器

一台别人捐助的服务器，LJ最初就跑在上面，就像Google开始时候用的破服务器一样，值得我们尊敬。这个阶段，LJ的人以惊人的速度熟悉的Unix的操作管理，服务器性能出现过问题，不过还好，可以通过一些小修小改应付过去。在这个阶段里LJ把CGI升级到了FastCGI。

最终问题出现了，网站越来越慢，已经无法通过优过化来解决的地步，需要更多的服务器，这时LJ开始提供付费服务，可能是想通过这些钱来购买新的服务器，以解决当时的困境。
毫无疑问，当时LJ存在巨大的单点问题，所有的东西都在那台服务器的铁皮盒子里装着。

2、两台服务器

用付费服务赚来的钱LJ买了两台服务器：一台叫做Kenny的Dell 6U机器用于提供Web服务，一台叫做Cartman的Dell 6U服务器用于提供数据库服务。

LJ有了更大的磁盘，更多的计算资源。但同时网络结构还是非常简单，每台机器两块网卡，Cartman通过内网为Kenny提供MySQL数据库服务。

暂时解决了负载的问题，新的问题又出现了：

• 原来的一个单点变成了两个单点。
• 没有冷备份或热备份。
• 网站速度慢的问题又开始出现了，没办法，增长太快了。
• Web服务器上CPU达到上限，需要更多的Web服务器。

3、四台服务器

又买了两台，Kyle和Stan，这次都是1U的，都用于提供Web服务。目前LJ一共有3台Web服务器和一台数据库服务器。这时需要在3台Web服务器上进行负载均横。

LJ把Kenny用于外部的网关，使用mod_backhand进行负载均横。

然后问题又出现了：

• 单点故障。数据库和用于做网关的Web服务器都是单点，一旦任何一台机器出现问题将导致所有服务不可用。虽然用于做网关的Web服务器可以通过保持心跳同步迅速切换，但还是无法解决数据库的单点，LJ当时也没做这个。
• 网站又变慢了，这次是因为IO和数据库的问题，问题是怎么往应用里面添加数据库呢？

4、五台服务器

又买了一台数据库服务器。在两台数据库服务器上使用了数据库同步(Mysql支持的Master-Slave模式)，写操作全部针对主数据库（通过Binlog，主服务器上的写操作可以迅速同步到从服务器上），读操作在两个数据库上同时进行(也算是负载均横的一种吧)。

实现同步时要注意几个事项：

• 读操作数据库选择算法处理，要选一个当前负载轻一点的数据库。
• 在从数据库服务器上只能进行读操作
• 准备好应对同步过程中的延迟，处理不好可能会导致数据库同步的中断。只需要对写操作进行判断即可，读操作不存在同步问题。

5、更多服务器

有钱了，当然要多买些服务器。部署后快了没多久，又开始慢了。这次有更多的Web服务器，更多的数据库服务器，存在 IO与CPU争用。于是采用了BIG-IP作为负载均衡解决方案。

6、现在我们在哪里：

现在服务器基本上够了，但性能还是有问题，原因出在架构上。

数据库的架构是最大的问题。由于增加的数据库都是以Slave模式添加到应用内，这样唯一的好处就是将读操作分布到了多台机器，但这样带来的后果就是写操作被大量分发，每台机器都要执行，服务器越多，浪费就越大，随着写操作的增加，用于服务读操作的资源越来越少。

由一台分布到两台

最终效果

现在我们发现，我们并不需要把这些数据在如此多的服务器上都保留一份。服务器上已经做了RAID，数据库也进行了备份，这么多的备份完全是对资源的浪费，属于冗余极端过度。那为什么不把数据分布存储呢？

问题发现了，开始考虑如何解决。现在要做的就是把不同用户的数据分布到不同的服务器上进行存储，以实现数据的分布式存储，让每台机器只为相对固定的用户服务，以实现平行的架构和良好的可扩展性。

为了实现用户分组，我们需要为每一个用户分配一个组标记，用于标记此用户的数据存放在哪一组数据库服务器中。每组数据库由一个master及几个slave组成，并且slave的数量在2-3台，以实现系统资源的最合理分配，既保证数据读操作分布，又避免数据过度冗余以及同步操作对系统资源的过度消耗。

由一台（一组）中心服务器提供用户分组控制。所有用户的分组信息都存储在这台机器上，所有针对用户的操作需要先查询这台机器得到用户的组号，然后再到相应的数据库组中获取数据。

这样的用户架构与目前LJ的架构已经很相像了。

在具体的实现时需要注意几个问题：

• 在数据库组内不要使用自增ID，以便于以后在数据库组之间迁移用户，以实现更合理的I/O，磁盘空间及负载分布。
• 将userid，postid存储在全局服务器上，可以使用自增，数据库组中的相应值必须以全局服务器上的值为准。全局服务器上使用事务型数据库InnoDB。
• 在数据库组之间迁移用户时要万分小心，当迁移时用户不能有写操作。

7、现在我们在哪里

问题：

• 一个全局主服务器，挂掉的话所有用户注册及写操作就挂掉。
• 每个数据库组一个主服务器，挂掉的话这组用户的写操作就挂掉。
• 数据库组从服务器挂掉的话会导致其它服务器负载过大。

对于Master-Slave模式的单点问题，LJ采取了Master-Master模式来解决。所谓Master-Master实际上是人工实现的，并不是由MySQL直接提供的，实际上也就是两台机器同时是Master，也同时是Slave，互相同步。

Master-Master实现时需要注意：

• 一个Master出错后恢复同步，最好由服务器自动完成。
• 数字分配，由于同时在两台机器上写，有些ID可能会冲突。

解决方案：

• 奇偶数分配ID，一台机器上写奇数，一台机器上写偶数
• 通过全局服务器进行分配(LJ采用的做法)。

Master-Master模式还有一种用法，这种方法与前一种相比，仍然保持两台机器的同步，但只有一台机器提供服务（读和写），在每天晚上的时候进行轮换，或者出现问题的时候进行切换。

8、现在我们在哪里

现在插播一条广告，MyISAM VS InnoDB。

使用InnoDB：

• 支持事务
• 需要做更多的配置，不过值得，可以更安全的存储数据，以及得到更快的速度。

使用MyISAM：

• 记录日志（LJ用它来记网络访问日志）
• 存储只读静态数据，足够快。
• 并发性很差，无法同时读写数据（添加数据可以）
• MySQL非正常关闭或死机时会导致索引错误，需要使用myisamchk修复，而且当访问量大时出现非常频繁。

9、缓存

去年我写过一篇文章介绍memcached，它就是由LJ的团队开发的一款缓存工具，以key-value的方式将数据存储到分布的内存中。LJ缓存的数据：

• 12台独立服务器（不是捐赠的）
• 28个实例
• 30GB总容量
• 90-93%的命中率（用过squid的人可能知道，squid内存加磁盘的命中率大概在70-80%）

如何建立缓存策略？

想缓存所有的东西？那是不可能的，我们只需要缓存已经或者可能导致系统瓶颈的地方，最大程度的提交系统运行效率。通过对MySQL的日志的分析我们可以找到缓存的对象。

缓存的缺点？

• 没有完美的事物，缓存也有缺点：
• 增大开发量，需要针对缓存处理编写特殊的代码。
• 管理难度增加，需要更多人参与系统维护。
• 当然大内存也需要钱。

10、Web访问负载均衡

在数据包级别使用BIG-IP，但BIG-IP并不知道我们内部的处理机制，无法判断由哪台服务器对这些请求进行处理。反向代理并不能很好的起到作用，不是已经够快了，就是达不到我们想要的效果。

所以，LJ又开发了Perlbal。特点：

• 快，小，可管理的http web 服务器/代理
• 可以在内部进行转发
• 使用Perl开发
• 单线程，异步，基于事件，使用epoll , kqueue
• 支持Console管理与http远程管理，支持动态配置加载
• 多种模式：web服务器，反向代理，插件
• 支持插件：GIF/PNG互换？

11、MogileFS

LJ使用开源的MogileFS作为分布式文件存储系统。MogileFS使用非常简单，它的主要设计思想是：

• 文件属于类（类是最小的复制单位）
• 跟踪文件存储位置
• 在不同主机上存储
• 使用MySQL集群统一存储分布信息
• 大容易廉价磁盘

到目前为止就这么多了，更多文档可以在http://www.danga.com/words/找到。Danga.com和LiveJournal.com的同学们拿这个文档参加了两次MySQL Con，两次OS Con，以及众多的其它会议，无私的把他们的经验分享出来，值得我们学习。在web2.0时代快速开发得到大家越来越多的重视，但良好的设计仍是每一个应用的基础，希望web2.0们在成长为Top500网站的路上，不要因为架构阻碍了网站的发展。

参考资料：http://www.danga.com/words/2005_oscon/oscon-2005.pdf

感谢向静推荐了这篇文档给我。

http://blog.csdn.net/yzhz/archive/2005/02/24/300500.aspx

eBay架构的思想金矿 收藏
英文来源：http://www.manageability.org/blog/stuff/about-ebays-architecture

                        杨争  /译

       了解一件事情是怎么做的一个正确的方式是看看它在现实中是怎么做的。软件工业一直以来都在为"很多idea仅仅在理论上说说"所困惑。与此同时，软件厂商不断地把这些idea作为最佳实践推销给大家。
        很少的软件开发者亲眼目睹过大规模可扩展的架构这一领域。幸运的是，有时我们可以看到和听到关于这方面公开发表的资料。我读过一些好的资料关于google的硬件基础设施的设计以及yahoo的页面渲染专利。现在，另一个互连网的巨人，eBay，给我们提供了其架构的一些资料（译者注：指的是"一天十亿次的访问－采用Core J2EE Pattern架构的J2EE 系统"这篇文章）。
        这篇文章提供了很多信息。然而，我们将只对那些独特的和我感兴趣的那部分进行评论。
        给我留下深刻印象是eBay站点的99.92%的可用性和380M page的页面数据。除此之外，每周近3万行代码的改动，清楚明白地告诉我们ebay的java代码的高度扩展性。
        eBay使用J2EE技术是如何做到这些的。eBay可扩展性的部分如下：
 
              Judicious use of server-side state
              No server affinity
              Functional server pools
              Horizontal and vertical database partitioning

        eBay取得数据访问的线性扩展的做法是非常让人感兴趣的。他们提到使用"定制的O-R mapping" 来支持本地Cache和全局Cache、lazy loading, fetch sets (deep and shallow)以及读取和提交更新的子集。 而且，他们只使用bean管理的事务以及使用数据库的自动提交和O-R mapping来route不同的数据源.
       有几个事情是非常令人吃惊的。第一，完全不使用Entity Beans,只使用他自己的O-R mapping工具(Hibernate anyone?)。 第二、基于Use-Case的应用服务器划分。第三、数据库的划分也是基于Use-Case。最后是系统的无状态本性以及明显不使用集群技术。

       下面是关于服务器状态的引用：
       基本上我们没有真正地使用server-side state。我们可能使用它，但现在我们并没有找到使用它的理由。....。如果需要状态化的话，我们把状态放到数据库中;需要的时候我们再从数据库中取。我们不必使用集群。也就不用为集群做任何工作。

        总之，你自己不必为架构一台有状态的服务器所困扰，更进一步，忘掉集群，你不需要它。现在看看功能划分：
 
       我们有一组或者一批机器，上面运行的应用是某个具体的use case，比如搜索功能有他们自己的服务器群，我们可以采用不同的调优策略，原因是浏览商品这个基本上是只读的用例和卖一件商品这个读写的用例在执行的时候是不同。在过去四五年我们一直采用水平数据库划分达到我们需要的可用性和线性扩展性。

        总之，不要把你的应用和数据库放在一个giant machine，仅仅使用servers pools，每个pools对应一个Use Case. 听起来是否类似Google的策略。

        下面是关于水平划分的一些介绍：
         基于内容的路由可以实现系统的水平线性扩展。所以，想象一下，如果eBay某天拥有6000万种商品，我们不必把这些数据存储到一台超级Sun服务器上。.....也许我们可以把这些数据库放到许多台Sun服务器,但是我们怎么取到我们需要的数据呢？eBay提出了基于内容路由的方法. 这种方法通过一定的规则，从20台物理服务器中找到我需要的数据。更cool的事情是这里还定义了failover的策略。

        最后，下面一句话描述了未来采用更加松散耦合的架构：
 
       使用消息系统来耦合不同的Use Case是我们研究的内容。

        是不是觉得很奇怪，最初这篇文章是介绍J2EE设计模式的？关键的线性扩展的思想几乎和Patterns无关。是的，eBay采用设计模式组织他们的代码。然而过分强调设计模式将失去对整体的把握。eBay架构关键的思想是无状态的设计，使用灵活的，高度优化的 OR-mapping 层以及服务器基于use cases划分。设计模式是好的，然而不能期望它使应用具有线性扩展性。

        总之，eBay和Google的例子表明以Use-Case为基础组成的服务器pools的架构比几个大型计算机证明是具有更好线性扩展性的和可用性。当然，厂商害怕听到这样的结论。然而，部署这么多服务器的最大麻烦是如何管理好他们。-)

我的总结：
         eBay采用设计模式达到eBay架构的分层，各层（表示层、商业逻辑层、数据访问层）之间松散耦合，职责明确，分层提高了代码的扩展性和程序开发的效率。
         eBay采用无状态的设计，灵活的、高度优化的 OR-mapping 层以及服务器基于use cases划分，达到应用之间的松散耦合，提高系统的线性扩展性。
        为什么要求系统具有可线性扩展，目的就是当网站的访问量上升的时候，我们可以不用改动系统的任何代码，仅仅通过增加服务器就可以提高整个网站的支撑量。

http://blog.csdn.net/yzhz/archive/2005/01/10/247116.aspx

一天十亿次的访问－eBay架构（一） 收藏
版权声明：如有转载请求，请注明出处：http://blog.csdn.net/yzhz

本文来自于2003JavaOne（http://java.sun.com/javaone/）上的一篇文章。我把它翻译成中文，有些不重要的部分我已略去。虽然是2003年的文章，但其中的J2EE设计方案还是值得我们去学习的，而且这个架构本身就是面向未来的。

eBay作为全球最大的网络交易市场赢得了市场的尊重，作为技术人员我们对其后台架构如何能够支撑起这个庞然大物都会感兴趣。每天十亿次访问量，6900万注册会员，1600万商品这些天文般的数字意味着它每天承受着巨大的并发访问量，而且eBay上大量页面都不是静态页面。

这篇介绍eBay架构的文章一定能对我们的项目设计和开发起到很好的指导作用。

eBay的架构是eBay的工程师和Sun的工程师共同设计完成的。

下面文章中斜体字是我的注释或者感想，其他的都是原文翻译。

作者：Deepak Alur、Arnold Goldberg、Raj Krishnamurthy

翻译：杨争

一天十亿次的访问

采用Core J2EE Pattern架构的J2EE 系统

详细了解Core J2EE Pattern可以查看此链接http://java.sun.com/blueprints/corej2eepatterns/Patterns/

目标：

通过本文，学习如何采用Core J2EE Patterns架构具有高度扩展性多层的J2EE应用。

作者：

Deepak Alur

- Senior Software Architect, SunPS program

- Co-author of Core J2EE Patterns

- Sun-eBay V3 Architecture—Team leader

Arnold Goldberg

- Lead Architect—eBay.com Platform

- Led V3 architecture, design and implementation

Raj Krishnamurthy

- Software Architect, SunPS program

- Sun-eBay V3 Architecture team—Key member

议程：

入门和Core J2EE Patterns

eBay.com三层架构的目标

关键架构和技术决策

eBay.com如何应用Core J2EE Patterns

结论

一、入门和Core J2EE Patterns

1、目标：

- eBay.com网站的架构

- 架构中模式的地位

- 使用 Core J2EE Patterns的好处

2、eBay介绍

（1）使命

1、全球交易平台

2、拍卖、定价、B2C、B2B

（2）统计数据

- 6900万注册会员

- 28000个分类，1600万商品

- 2002年营业额：148亿7千万美元

-全球社区

-每天十亿次访问量

- 1200多个URL

3、eBay旧的二层架构及其存在的问题

（1）ebay旧的二层架构

-集成在一起的两层架构（架构中各组件之间的耦合度高）

- 330万行C++ ISAPI DLL

-面向功能的设计

- Not for systemic qualities

（2）二层架构存在的问题

-阻碍商业创新（可扩展性不够）

-随着访问量增大，系统线性扩展性面临着挑战（无法通过仅仅增加硬件投入，扩充系统的支撑量）

-高额的维护成本

-不便于“重构”（代码很难通过重构来改善）

- Architects in constant Fire-Fighting Mode

4、2000年底开始三层架构改造

系统向分层、松散耦合、模块化、基于标准的架构过渡