Scale-out solutions - spreading the load among multiple slaves to improve performance. In this environment, all writes and updates must take place on the master server. Reads, however, may take place on one or more slaves. This model can improve the performance of writes (since the master is dedicated to updates), while dramatically increasing read speed across an increasing number of slaves.
Data security - because data is replicated to the slave, and the slave can pause the replication process, it is possible to run backup services on the slave without corrupting the corresponding master data.
Analytics - live data can be created on the master, while the analysis of the information can take place on the slave without affecting the performance of the master.
Long-distance data distribution - if a branch office would like to work with a copy of your main data, you can use replication to create a local copy of the data for their use without requiring permanent access to the master?br />
1、复制进E?/strong>
Mysql的复ӞReplicationQ是一个异步的复制Q从一个Mysql instaceQ称之ؓMasterQ复制到另一个Mysql
instanceQ称之SlaveQ。实现整个复制操作主要由三个q程完成的,其中两个q程在SlaveQSqlq程和IOq程Q,另外一个进E在
MasterQIOq程Q上?br />
要实施复Ӟ首先必须打开Master端的binary logQbin-logQ功能,否则无法实现。因为整个复制过E实际上是Slave从Master端获取该日志然后再在自己w上完全序的执行日志中所记录的各U操作?br />
复制的基本过E如下:
1)、Slave上面的IOq程q接上MasterQƈh从指定日志文件的指定位置Q或者从最开始的日志Q之后的日志内容Q?br />
2)、Master接收到来自Slave的IOq程的请求后Q通过负责复制的IOq程Ҏh信息d制定日志指定位置之后的日志信息,q回lSlave
的IOq程。返回信息中除了日志所包含的信息之外,q包括本ơ返回的信息已经到Master端的bin-log文g的名UC及bin-log的位|;
3)、Slave的IOq程接收C息后Q将接收到的日志内容依次d到Slave端的relay-log文g的最末端Qƈ读取到的Master端的
bin-log的文件名和位|记录到master-info文g中,以便在下一ơ读取的时候能够清楚的告诉Master“我需要从某个bin-log的哪
个位|开始往后的日志内容Q请发给?#8221;Q?br />
4)、Slave的Sqlq程到relay-log中新增加了内容后Q会马上解析relay-log的内Ҏ为在Master端真实执行时候的那些可执行的内容Qƈ在自w执行?br />
实际上在老版本的Mysql的复制实现在Slave端ƈ不是两个q程完成的,而是׃个进E完成。但是后来发现这样做存在较大的风险和性能问题Q主要如下:
首先Q一个进E就使复制bin-log日志和解析日志ƈ在自w执行的q程成ؓ一个串行的q程Q性能受到了一定的限制Q异步复制的延迟也会比较ѝ?br />
另外QSlave端从Master端获取bin-logq来之后Q需要接着解析日志内容Q然后在自n执行。在q个q程中,Master端可能又产生了大?
变化q声UC大量的日志。如果在q个阶段Master端的存储出现了无法修复的错误Q那么在q个阶段所产生的所有变更都永q无法找回。如果在Slave
端的压力比较大的时候,q个q程的时间可能会比较ѝ?br />
所以,后面版本的MysqlZ解决q个风险q提高复制的性能Q将Slave端的复制改ؓ两个q程来完成。提个改q方案的人是Yahoo!的一位工E?
?#8220;Jeremy
Zawodny”。这h解决了性能问题Q又~短了异步的延时旉Q同时也减少了可能存在的数据丢失量。当Ӟ即是换成了现在q样两个U程处理以后Q同
样也q是存在slave数据延时以及数据丢失的可能性的Q毕竟这个复制是异步的。只要数据的更改不是在一个事物中Q这些问题都是会存在的。如果要完全避免
q些问题Q就只能用mysql的cluster来解决了。不qmysql的cluster是内存数据库的解x案,需要将所有数据都load到内存中Q这
样就对内存的要求非常大了,对于一般的应用来说可实施性不是太大?br />
2、复制实现?/strong>
Mysql的复制可以是Z一条语句(Statement levelQ,也可以是Z一条记录(Row levelQ,可以在Mysql的配|参C讑֮q个复制U别Q不同复制别的讄会媄响到Master端的bin-log记录成不同的形式?br />
Row LevelQ日志中会记录成每一行数据被修改的Ş式,然后在slave端再对相同的数据q行修改?br />
优点Q在row
level模式下,bin-log中可以不记录执行的sql语句的上下文相关的信息,仅仅只需要记录那一条记录被修改了,修改成什么样了。所以row
level的日志内容会非常清楚的记录下每一行数据修改的l节Q非常容易理解。而且不会出现某些特定情况下的存储q程Q或functionQ以?
trigger的调用和触发无法被正复制的问题?br />
~点Qrow
level下,所有的执行的语句当记录到日志中的时候,都将以每行记录的修改来记录,q样可能会生大量的日志内容Q比如有q样一条update?
句:update product set owner_member_id = ‘b’ where owner_member_id =
‘a’Q执行之后,日志中记录的不是q条update语句所对应额事Ӟmysql以事件的形式来记录bin-log日志Q,而是q条语句所更新的每一?
记录的变化情况,q样p录成很多条记录被更新的很多个事g。自Ӟbin-log日志的量׃很大。尤其是当执行alter
table之类的语句的时候,产生的日志量是惊人的。因为Mysql对于alter
table之类的表l构变更语句的处理方式是整个表的每一条记录都需要变动,实际上就是重Z整个表。那么该表的每一条记录都会被记录到日志中?br />
Statement Level:每一条会修改数据的sql都会记录?master的bin-log中。slave在复制的时候sqlq程会解析成和原来master端执行过的相同的sql来再ơ执行?br />
优点Qstatement level下的优点首先是解决了row level下的~点Q不需要记录每一行数据的变化Q减bin-log日志量,节约IOQ提高性能。因Z只需要记录在Master上所执行的语句的l节Q以及执行语句时候的上下文的信息?br />
~点Q由于他是记录的执行语句Q所以,Z让这些语句在slave端也能正执行,那么他还必须记录每条语句在执行的时候的一些相关信息,也就是上下文?
息,以保证所有语句在slave端杯执行的时候能够得到和在master端执行时候相同的l果。另外就是,׃Mysql现在发展比较快,很多的新功能?
断的加入Qmysql得复刉C不小的挑战,自然复制的时候涉及到复杂的内容Qbug也就容易出现。在statement
level下,目前已经发现的就有不情况会造成mysql的复制出现问题,主要是修Ҏ据的时候用了某些特定的函数或者功能的时候会出现Q比
如:sleep()函数在有些版本中׃能真复Ӟ在存储过E中使用了last_insert_id()函数Q可能会使slave和master上得?
不一致的id{等。由于row level是基于每一行来记录的变化,所以不会出现类似的问题?/font>
With statement-based replication, you may encounter issues with replicating stored routines or triggers. You can avoid these issues by using row-based replication instead.
从官Ҏ档中看到Q之前的Mysql一直都只有Zstatement的复制模式,直到5.1.5版本的Mysql才开始支持row level的复制。从5.0开始,Mysql的复制已l解决了大量老版本中出现的无法正复制的问题。但是由于存储过E的出现Q给Mysql的复制又带来 了更大的新挑战。另外,看到官方文档_?.1.8版本开始,Mysql提供了除Statement Level和Row Level之外的第三种复制模式QMixedQ实际上是前两U模式的l合?/font>
From MySQL 5.1.12 to MySQL 5.1.28, mixed format is the default. Beginning with MySQL 5.1.29, statement-based format is the default.
在Mixed模式下,Mysql会根据执行的每一条具体的sql语句来区分对 待记录的日志形式Q也是在Statement和Row之间选择一U。新版本中的Statment levelq是和以前一P仅仅记录执行的语句。而新版本的Mysql中队row level模式也被做了优化Qƈ不是所有的修改都会以row level来记录,像遇到表l构变更的时候就会以statement模式来记录,如果sql语句实是update或者delete{修Ҏ据的语句Q? 那么q是会记录所有行的变更?br />
3、复制常用架?/strong>1. 如果不徏立烦引,那么查询都需要全表扫描;如果建立了烦引,则数据库会保存一个烦引文仉常是特D的l构比如B树,q样查询h不需要全表扫描,一下子能够扑ֈ满要求的记录?/span>
2. 一般是?/span>Where之后的条件徏立烦引,数据库中的主键是已经建立了烦引的。数据库中可以徏立多个烦引?/span>
3. 可以对不同类型的列徏立烦引?/span>
对于Textcd{,可以使用MySQL的全文检索功能徏立全文烦引。它利用了自然语a的方法去在文本中索关键词?/span>
举个例子Q如果?/span>=L话可能需要?/span>like以及%{去匚w。而?/span>MySQL的全文检索可以?/span>Match函数卛_索出包含关键词的列?/span>
详细情况参看MySQL参考手册关于全文检索的部分?/span>
4.1使用索引
我们首先讨论索引Q因为它是加快查询的最重要的工兗还有其他加快查询的技术,但是最有效的莫q于恰当C用烦引了。在MySQL的邮件清单上Qh们通常询问关于使查询更快的问题。在大量的案例中Q都是因上没有烦引,一般只要加上烦引就可以立即解决问题。但q样也ƈ非L有效Q因Z化ƈ非L那样单。然而,如果不用烦引,在许多情形下Q用其他手段改善性能只会是浪Ҏ间。应该首先考虑使用索引取得最大的性能改善Q然后再L其他可能有帮助的技术?/span>
本节介绍索引是什么、它怎样改善查询性能、烦引在什么情况下可能会降低性能Q以及怎样选择索引。下一节,我们讨?/span>MySQL的查询优化程序。除了知道怎样创徏索引外,了解一些优化程序的知识也是有好处的Q因样可以更好地利用所创徏的烦引。某些编写查询的Ҏ实际上会妨碍索引的效果,应该避免q种情况出现。(虽然qMq样。有时也会希望忽略优化程序的作用。我们也介l这些情c)
4.1.1索引的益?/span>
让我们从一个无索引的表着手来考察索引是怎样起作用的。无索引的表是一个无序的行集。例如,?/span>4 - 1l出了我们在W?/span>1?#8220;MySQL?/span>SQL 介绍” 中首先看到的ad 表。这个表上没有烦引,因此如果我们查找某个特定公司的行Ӟ必须查看表中的每一行,看它是否与所需的值匹配。这是一个全表扫描,很慢Q如果表中只有少数几个记录与搜烦条g相匹配,则其效率是相当低的?/span>
?/span>4 - 2l出了相同的表,但在表的company_num 列上增加了一个烦引。此索引包含表中每行的一,但此索引是在company_num 上排序的。现在,不需要逐行搜烦全表查找匚w的条ƾ,而是可以利用索引q行查找。假如我们要查找公司13的所有行Q那么可以扫描烦引,l果得出3行。然后到辑օ?/span>14的行Q这是一个比我们正在查找的要大的L。烦引值是排序的,因此在读到包?/span>14的记录时Q我们知道不会再有匹配的记录Q可以退Z。如果查找一个|它在索引表中某个中间点以前不会出玎ͼ那么也有扑ֈ其第一个匹配烦引项的定位算法,而不用进行表的顺序扫描(如二分查找法Q。这P可以快速定位到W一个匹配的|以节省大量搜索时间。数据库利用了各U各L快速定位烦引值的技术,q些技术是什么ƈ不重要,重要的是它们工作正常Q烦引技术是个好东西?/span>
有h会问Qؓ什么不只对数据文gq行排序Q省掉烦引文Ӟq样不也在搜索时产生相同的效果吗Q问得好Q如果只有单个烦引时Q?/span>
是这L。不q有可能会用到第二个索引Q但同时以两U不同的Ҏ对同一个数据文件进行排序是不可能的。(如,惌一个顾客名的烦
引,同时又要一个顾?/span>ID h电话L的烦引。)烦引文件作Z个与数据文g独立的实体就解决了这个问题,而且允许创徏多个?/span>
引。此外,索引中的行一般要比数据文件中的行短。在插入或删除值时Qؓ保持排序序而移动较短的索引gUd较长的数据行相比?/span>
为容易?/span>
q个例子?/span>MySQL索引表的Ҏ相符。表的数据行保存在数据文件中Q而烦引g存在索引文g中。一个表上可有不止一个烦引;如果实有不止一个烦引,它们都保存在同一个烦引文件中。烦引文件中的每个烦引由排过序的用来快速访问数据文件的键记录数l构成?/span>
前面的讨论描qC单表查询中烦引的好处Q其中用烦引消除了全表扫描Q极大地加快了搜索的速度。在执行涉及多个表的q接查询Ӟ索引甚至会更有h倹{在单个表的查询中,每列需要查看的值的数目是表中行的数目。而在多个表的查询中,可能的组合数目极大,因ؓq个数目为各表中行数之积?/span>
假如有三个未索引的表t 1?/span>t 2?/span>t 3Q分别只包含?/span>c 1?/span>c 2?/span>c 3Q每个表分别由含有数?/span>1?/span>1000 ?/span>1000 行组成。查扑֯应值相{的表行l合的查询如下所C:
SELECT c1,c2,c3
FROM t1,t2,t3
WHERE c1=c2 AND c1=c3
此查询的l果应该?/span>1000 行,每个l合包含3 个相{的倹{如果我们在无烦引的情况下处理此查询Q则不可能知道哪些行包含那些倹{因此,必须L出所有组合以便得ZWHERE 子句盔R的那些组合。可能的l合数目?/span>10 0 0??0 0 0??0 0 0Q十亿)Q比匚w数目多一百万倍。很多工作都费了,q且q个查询会非常慢,即在如?/span>MySQLq样快的数据库中执行也会很慢。而这q是每个表中只有1000 行的情Ş。如果每个表中有一百万行时Q将会怎样Q很昄Q这样将会生性能极ؓ低下的结果。如果对每个表进行烦引,p极大地加速查询进E,因ؓ利用索引的查询处理如下:
1) 如下从表t1中选择W一行,查看此行所包含的倹{?/span>
2) 使用?/span>t2 上的索引Q直接蟩?/span>t2 中与来自t1的值匹配的行。类|利用?/span>t3 上的索引Q直接蟩?/span>t3 中与来自t1的值匹配的行?/span>
3) q到?/span>t1的下一行ƈ重复前面的过E直?/span>t1中所有的行已l查q。在此情形下Q我们仍然对?/span>t1执行了一个完全扫描,但能够在?/span>t2 ?/span>t3 上进行烦引查扄接取些表中的行。从道理上说Q这时的查询比未用烦引时要快一百万倍。如上所qͼMySQL利用索引加速了WHERE 子句中与条g盔R的行的搜索,或者说在执行连接时加快了与其他表中的行匚w的行的搜索。它也利用烦引来改进其他操作的性能Q?/span>
?/span> 在?/span>MIN( ) ?/span>MAX( ) 函数Ӟ能够快速找到烦引列的最或最大倹{?/span>
?/span> MySQL常常能够利用索引来完?/span>ORDER BY 子句的排序操作?/span>
?/span> 有时Q?/span>MySQL可避免对整个数据文g的读取。假如从一个烦引数值列中选择|而且不选择表中其他列。这Ӟ通过对烦引值的dQ就已经得到了读取数据文件所要得到的倹{没有对相同的D行两ơ读取的必要Q因此,甚至无需涉及数据文g?/span>
4.1.2 索引的弊?/span>
一般情况下Q如?/span>MySQL能够知道怎样用烦引来更快地处理查询,它就会这样做。这表示Q在大多数情况下Q如果您不对表进行烦引,则损害的是您自己的利益。可以看出,作者描l了索引的诸多好处。但有不利之处吗Q是的,有。实际上Q这些缺点被优点所掩盖了,
但应该对它们有所了解?/span>
首先Q烦引文件要占磁盘空间。如果有大量的烦引,索引文g可能会比数据文g更快地达到最大的文g寸。其ơ,索引文g加快了检索,但增加了插入和删除,以及更新索引列中的值的旉Q即Q降低了大多数涉及写入的操作的时_Q因为写操作不仅涉及数据行,而且q常常涉及烦引。一个表拥有的烦引越多,则写操作的^均性能下降p大。在4 . 4?#8220;有效地装载数?#8221;中,我们更l地介绍q些性能问题Qƈ讨论怎样解决?/span>
4.1.3 选择索引
创徏索引的语法已l在3 . 4 . 3?#8220;创徏和删除烦?#8221;中进行了介绍。这里,我们假定您已l阅读过该节。但是知道语法ƈ不能帮助定表怎样q行索引。要军_表怎样q行索引需要考虑表的使用方式。本节介l一些关于怎样定和挑选烦引列的准则:
?/span> 搜烦的烦引列Q不一定是所要选择的列。换句话_最适合索引的列是出现在WHERE 子句中的列,或连接子句中指定的列Q而不是出现在SELECT 关键字后的选择列表中的列:
当然Q所选择的列和用?/span>WHERE 子句的列也可能是相同的。关键是Q列出现在选择列表中不是该列应该烦引的标志。出现在q接子句中的列或出现在Ş?/span>col1= col2 的表辑ּ中的列是很适合索引的列。查询中?/span>col_b ?/span>col_c 是q样的例子。如?/span>MySQL能利用连接列来优化一个查询,表示它通过消除全表扫描相当可观地减了表行的组合?/span>
?/span> 使用惟一索引。考虑某列中值的分布。对于惟一值的列,索引的效果最好,而具有多个重复值的列,其烦引效果最差。例如,存放q龄的列h不同|很容易区分各行。而用来记录性别的列Q只含有“ M”?#8220;F”Q则Ҏ列进行烦引没有多大用处(不管搜烦哪个|都会得出大约一半的行)?/span>
?/span> 使用短烦引。如果对串列q行索引Q应该指定一个前~长度Q只要有可能应该这样做。例如,如果有一?/span>CHAR(200) 列,如果在前10 个或20 个字W内Q多数值是惟一的,那么׃要对整个列进行烦引。对?/span>10 个或20 个字W进行烦引能够节省大量烦引空_也可能会使查询更快。较的索引涉及的磁?/span>I/O 较少Q较短的值比较v来更快。更为重要的是,对于较短的键|索引高速缓存中的块能容Ux多的键|因此Q?/span>MySQL也可以在内存中容Ux多的倹{这增加了找到行而不用读取烦引中较多块的可能性。(当然Q应该利用一些常识。如仅用列值的W一个字W进行烦引是不可能有多大好处的,因ؓq个索引中不会有许多不同的倹{)
?/span> 利用最左前~。在创徏一?/span>n 列的索引Ӟ实际是创ZMySQL可利用的n 个烦引。多列烦引可起几个烦引的作用Q因为可利用索引中最左边的列集来匚w行。这L列集UCؓ最左前~。(q与索引一个列的前~不同Q烦引一个列的前~是利用该的前n 个字W作为烦引倹{)
假如一个表在分别名?/span>s t a t e?/span>city ?/span>zip 的三个列上有一个烦引。烦引中的行是按state/city/zip 的次序存攄Q因此,索引中的行也会自动按state/city 的顺序和state 的顺序存放。这表示Q即使在查询中只指定state 值或只指?/span>state ?/span>city 的|MySQL也可以利用烦引。因此,此烦引可用来搜烦下列的列l合Q?/span>
state,city,zip
state,city
sate
MySQL不能使用不涉及左前缀的搜索。例如,如果?/span>city ?/span>zip q行搜烦Q则不能使用该烦引。如果要搜烦某个州以及某?/span>zip 代码Q烦引中的列1和列3Q,则此索引不能用于相应值的l合。但是,可利用烦引来L与该州相W的行,以减搜索范围?/span>
在上U后QLiveJournal实现了非常快速的增长Q?/p>
LiveJournal?台服务器发展?00台服务器Q这其中l历了无数的伤痛Q但同时也摸索出了解册些问题的ҎQ通过对LiveJournal的学习,可以让我们避免LJ曄犯过的错误,q且从一开始就对系l进行良好的设计Q以避免后期的痛苦?/p>
下面我们一步一步看LJ发展的脚步?/p>
一台别人捐助的服务器,LJ最初就跑在上面Q就像Google开始时候用的破服务器一P值得我们敬。这个阶D,LJ的h以惊人的速度熟悉的Unix的操作管理,服务器性能出现q问题,不过q好Q可以通过一些小修小改应付过厅R在q个阶段里LJ把CGI升CFastCGI?/p>
最l问题出CQ网站越来越慢,已经无法通过优过化来解决的地步,需要更多的服务器,q时LJ开始提供付Ҏ务,可能是想通过q些钱来购买新的服务器,以解军_时的困境?br /> 毫无疑问Q当时LJ存在巨大的单炚w题,所有的东西都在那台服务器的铁皮盒子里装着?/p>
用付Ҏ务赚来的钱LJC两台服务器:一台叫做Kenny的Dell 6U机器用于提供Web服务Q一台叫做Cartman的Dell 6U服务器用于提供数据库服务?/p>
LJ有了更大的磁盘,更多的计资源。但同时|络l构q是非常单,每台机器两块|卡QCartman通过内网为Kenny提供MySQL数据库服务?br />
暂时解决了负载的问题Q新的问题又出现了:
又买了两収ͼKyle和StanQ这ơ都?U的,都用于提供Web服务。目前LJ一共有3台Web服务器和一台数据库服务器。这旉要在3台Web服务器上q行负蝲均横?/p>
LJ把Kenny用于外部的网养I使用mod_backhandq行负蝲均横?/p>
然后问题又出CQ?/p>
又买了一台数据库服务器。在两台数据库服务器上用了数据库同?Mysql支持的Master-Slave模式)Q写操作全部针对L据库Q通过BinlogQ主服务器上的写操作可以q速同步到从服务器上)Q读操作在两个数据库上同时进?也算是负载均横的一U吧)?/p>
实现同步时要注意几个事项Q?/p>
有钱了,当然要多C服务器。部|后快了没多久,又开始慢了。这ơ有更多的Web服务器,更多的数据库服务器,存在 IO与CPU争用。于是采用了BIG-IP作ؓ负蝲均衡解决Ҏ?/p>
现在服务器基本上够了Q但性能q是有问题,原因出在架构上?/p>
数据库的架构是最大的问题。由于增加的数据库都是以Slave模式d到应用内Q这样唯一的好处就是将L作分布到了多台机器,但这样带来的后果是写操作被大量分发Q每台机器都要执行,服务器越多,费p大,随着写操作的增加Q用于服务读操作的资源越来越?/p>
׃台分布到两台
最l效?/p>
现在我们发现Q我们ƈ不需要把q些数据在如此多的服务器上都保留一份。服务器上已l做了RAIDQ数据库也进行了备䆾Q这么多的备份完全是对资源的费Q属于冗余极端过度。那Z么不把数据分布存储呢Q?/p>
问题发现了,开始考虑如何解决。现在要做的是把不同用L数据分布C同的服务器上q行存储Q以实现数据的分布式存储Q让每台机器只ؓ相对固定的用h务,以实现^行的架构和良好的可扩展性?/p>
Z实现用户分组Q我们需要ؓ每一个用户分配一个组标记Q用于标记此用户的数据存攑֜哪一l数据库服务器中。每l数据库׃个master及几个slavel成Qƈ且slave的数量在2-3収ͼ以实现系l资源的最合理分配Q既保证数据L作分布,又避免数据过度冗余以及同步操作对pȝ资源的过度消耗?/p>
׃収ͼ一l)中心服务器提供用户分l控制。所有用L分组信息都存储在q台机器上,所有针对用L操作需要先查询q台机器得到用户的组P然后再到相应的数据库l中获取数据?/p>
q样的用h构与目前LJ的架构已l很相像了?/p>
在具体的实现旉要注意几个问题:
问题Q?/p>
对于Master-Slave模式的单炚w题,LJ采取了Master-Master模式来解冟뀂所谓Master-Master实际上是人工实现的,q不是由MySQL直接提供的,实际上也是两台机器同时是MasterQ也同时是SlaveQ互相同步?/p>
Master-Master实现旉要注意:
解决ҎQ?br />
Master-Master模式q有一U用法,q种Ҏ与前一U相比,仍然保持两台机器的同步,但只有一台机器提供服务(d写)Q在每天晚上的时候进行轮换,或者出现问题的时候进行切换?/p>
现在插播一条广告,MyISAM VS InnoDB?/p>
使用InnoDBQ?/p>
使用MyISAMQ?/p>
d我写q?a >一文章介lmemcachedQ它是由LJ的团队开发的一Ƅ存工P以key-value的方式将数据存储到分布的内存中。LJ~存的数据:
如何建立~存{略Q?/p>
想缓存所有的东西Q那是不可能的,我们只需要缓存已l或者可能导致系l瓶颈的地方Q最大程度的提交pȝq行效率。通过对MySQL的日志的分析我们可以扑ֈ~存的对象?/p>
~存的缺点?
在数据包U别使用BIG-IPQ但BIG-IPq不知道我们内部的处理机Ӟ无法判断由哪台服务器对这些请求进行处理。反向代理ƈ不能很好的vC用,不是已经够快了,是达不到我们想要的效果?/p>
所以,LJ又开发了Perlbal。特点:
LJ使用开源的MogileFS作ؓ分布式文件存储系l。MogileFS使用非常单,它的主要设计思想是:
到目前ؓ止就q么多了Q更多文档可以在http://www.danga.com/words/扑ֈ?a >Danga.com?a >LiveJournal.com的同学们拿这个文档参加了两次MySQL ConQ两ơOS ConQ以及众多的其它会议Q无U的把他们的l验分n出来Q值得我们学习。在web2.0时代快速开发得到大家越来越多的重视Q但良好的设计仍是每一个应用的基础Q希望web2.0们在成长为Top500|站的\上,不要因ؓ架构ȝ了网站的发展?/p>