??xml version="1.0" encoding="utf-8" standalone="yes"?>狠狠亚洲狠狠欧洲2019,亚洲国产av一区二区三区丶,亚洲美女又黄又爽在线观看http://m.tkk7.com/paulwong/archive/2012/10/08/389204.htmlpaulwongpaulwongMon, 08 Oct 2012 13:38:00 GMThttp://m.tkk7.com/paulwong/archive/2012/10/08/389204.htmlhttp://m.tkk7.com/paulwong/comments/389204.htmlhttp://m.tkk7.com/paulwong/archive/2012/10/08/389204.html#Feedback0http://m.tkk7.com/paulwong/comments/commentRss/389204.htmlhttp://m.tkk7.com/paulwong/services/trackbacks/389204.htmlhttp://www.it168.com/redian/12306hpc/

paulwong 2012-10-08 21:38 发表评论
]]>?2306.cn谈谈|站性能技?/title><link>http://m.tkk7.com/paulwong/archive/2012/01/17/368659.html</link><dc:creator>paulwong</dc:creator><author>paulwong</author><pubDate>Tue, 17 Jan 2012 07:23:00 GMT</pubDate><guid>http://m.tkk7.com/paulwong/archive/2012/01/17/368659.html</guid><wfw:comment>http://m.tkk7.com/paulwong/comments/368659.html</wfw:comment><comments>http://m.tkk7.com/paulwong/archive/2012/01/17/368659.html#Feedback</comments><slash:comments>1</slash:comments><wfw:commentRss>http://m.tkk7.com/paulwong/comments/commentRss/368659.html</wfw:commentRss><trackback:ping>http://m.tkk7.com/paulwong/services/trackbacks/368659.html</trackback:ping><description><![CDATA[<div> 12306.cn|站挂了Q被全国人民骂了。我q两天也在思考这个事Q我想以q个事来_略地和大家讨论一下网站性能的问题。因Z促，而且完全Z 本h有限的经验和了解Q所以，如果有什么问题还请大家一赯论和指正。（q又是一长文，只讨论性能问题Q不讨论那些UIQ用户体验，或是是否把支付和?下单环节分开的功能性的东西Q? <h4>业务</h4> M技术都M开业务需求，所以，要说明性能问题Q首先还是想先说说业务问题? <ul> <li><strong>其一</strong>Q?strong>有h可能把这个东西和QQ或是|游相比</strong>。但我觉得这两者是不一LQ网游和QQ在线或是d时访问的更多的是用户自己的数据，而订系l访问的是中心的量数据Q这是不一L。不要觉得网游或是QQ能行你就以ؓq是一L。网游和QQ 的后端负载相对于电子商务的系l还是简单?/li> </ul> <ul> <li><strong>其二</strong>Q?strong>有h说春节期间订火R的这个事好像|站的秒杀zd</strong>。的很怼Q??是如果你的思考不在表面的话，你会发现q也有些不一栗火车票q个事，q有很多查询操作Q查旉Q查座位Q查ZQ一个Rơ不 行，又查另一个Rơ，其伴随着大量的查询操作，下单的时候需要对数据库操作。而秒杀Q直接杀好了。另外，关于U杀Q完全可以做成只接受前N个用Lh Q完全不操作后端的Q何数据， 仅仅只是对用L下单操作logQ，q种业务Q只要把各个服务器的旉_同步了就可以了，无需在当时操作Q何数据库。可以订单数够后Q停止秒杀Q然后批 量写数据库。火车票q个岂止是秒杀那么单。能不能买到得当时告诉用户啊?/li> </ul> <ul> <li><strong>其三</strong>Q?strong>有h拿这个系l和奥运会的务pȝ比较</strong>。我觉得q是不一栗虽然奥q会的票务系l当q也一上线废了。但是奥q会用的是抽奖的方式Q也是说不存在先来先得的抢的方式，而且Q是事后抽奖Q事前只需要收信息Q事前不需要保证数据一致性，没有锁，很容易水qx展?/li> </ul> <ul> <li><strong>其四</strong>Q?strong>订票pȝ应该和电子商务的订单pȝ很相?/strong>Q都是需要对库存q?行：1Q占住库存，2Q支付（可选）Q?Q扣除库存的操作。这个是需要有一致性的查的Q也是在ƈ发时需要对数据加锁的。B2C的电商基本上都会把这?事干成异步的Q也是_你下的订单ƈ不是马上处理的，而是延时处理的，只有成功处理了，pȝ才会l你一确认邮件说是订单成功。我怿有很多朋友都收到 认单不成功的邮g?strong>q就是说Q数据一致性在q发下是一个瓶?/strong>?/li> </ul> <ul> <li><strong>其五</strong>Q?strong>铁\的票务业务很变?/strong>Q其采用的是H然攄Q而有的票又远q不?大家分，所以，大家才会有抢这U有中国特色的业务的做法。于是当放出来的时候，׃有几百万人甚至上千万人杀上去Q查询，下单。几十分钟内Q一个网?能接受几千万的访问量Q这个是很恐怖的事情。据?2306的高峰访问是10亿PVQ集中在?点到10点，每秒PV在高峰时上千万?/li> </ul> 多说几句Q? <ul> <li><strong>库存是B2C的恶梦，库存理相当的复?/strong>。不信，你可以问问所有传l和电务零售业的企业Q看看他们管理库存是多么隄一件事。不Ӟ׃会有那么多h在问凡客的库存问题了。（你还可以看看《乔布斯传》，你就知道Z么Tim会接任Apple的CEO了，因ؓ他搞定了Ҏ的库存问题）</li> </ul> <ul> <li><strong>对于一个网站来_览|页的高负蝲很容易搞定，查询的负载有一定的隑ֺd理，不过q是可以通过~存查询l果来搞定，最隄是下单的负?/strong>。因讉K库存啊，对于下单Q基本上是用异步来搞定的。去q双11节，淘宝的每时的订单数大约?0万左叻I京东一天也才能支持40万（居然?2306q差Q，亚马?q前一时可支?0万订单量。可见，下订单的操作q没有我们相像的那么性能高?/li> </ul> <ul> <li><strong>淘宝要比B2C的网站要单得多，因ؓ没有仓库</strong>Q所以，不存在像B2Cq样有N个仓库对同一商品库存更新??询的操作。下单的时候，B2C?|站要去找一个仓库，又要ȝ戯Q又要有库存Q这需要很多计。试惻I你在北京C一本书Q北京的仓库没货了，p从周边的仓库调，那就要去看看沈阳?是西安的仓库有没有货Q如果没有，又得看看江苏的仓库，{等。淘宝的没有那么多事了Q每个商h自己的库存，库存分到商户头上了，反而有利于性能?/li> </ul> <ul> <li><strong>数据一致性才是真正的性能瓉</strong>。有 nginx可以搞定每秒10万的静态请求，我不怀疑。但q只是静态请求，理论|只要带宽、I/O够强Q服务器计算能力够，q支持的q发q接数顶得住 10万TCP链接的徏?的话Q那没有问题。但在数据一致性面前，q?0万就完完全全成了一个可望不可及的理论g?/li> </ul> 我说那么多，我只是想从业务上告诉大家Q我们需要从业务上真正了解春q铁路订这样业务的变态之处? <h4>前端性能优化技?/h4> 要解x能的问题，有很多种常用的方法，我在下面列D一下，我相?2306q个|站使用下面的这些技术会让其性能有质的飞跃? <h5>一、前端负载均?/h5> 通过DNS的负载均衡器Q一般在路由器上Ҏ路由的负载重定向Q可以把用户的访问均匀地分散在多个Web服务器上。这样可以减Web服务器的h 负蝲。因为http的请求都是短作业Q所以，可以通过很简单的负蝲均衡器来完成q一功能。最好是有CDN|络让用戯接与其最q的服务器（CDN通常伴随 着分布式存储）。（关于负蝲均衡更ؓ详细的说明见“后端的负载均?#8221;Q? <h5>二、减前端链接数</h5> 我看了一?2306.cnQ打开主页需要徏60多个HTTPq接QR预订页面则?0多个HTTPhQ现在的览器都是ƈ发请求的。所以，?要有100万个用户Q就会有6000万个链接Q太多了。一个登录查询页面就好了。把js打成一个文Ӟ把css也打成一个文Ӟ把图标也打成一个文Ӟ?css分块展示。把链接数减到最低? <h5>三、减网大增加带?/h5> q个世界不是哪个公司都敢做图片服务的Q因为图片太耗带宽了。现在宽带时代很难有体会到当拨号时代做个N都不敢用囄的情形（现在在手机端?览也是这个情形）。我查看了一?2306首页的需要下载的L件大大U在900KB左右Q如果你讉Kq了Q浏览器会帮你缓存很多，只需下蝲10K左右 的文件。但是我们可以想像一个极端一点的案例Q?百万用户同时讉KQ且都是W一ơ访问，每h下蝲量需?MQ如果需要在120U内q回Q那么就需要，1M * 1M /120 * 8 = 66Gbps的带宽。很惊h吧。所以，我估计在当天Q?2306的阻塞基本上应该是网l带宽，所以，你可能看到的是没有响应。后面随着览器的~存帮助 12306减少很多带宽占用Q于是负载一下就C后端Q后端的数据处理瓉一下就出来。于是你会看到很多http 500之类的错误。这说明服务器垮了? <h5>四、前端页面静态化</h5> 静态化一些不觉变的页面和数据Qƈgzip一下。还有一个ƈ态的Ҏ是把q些静态页面放?dev/shm下，q个目录是内存Q直接从内存中把文gd来返回，q样可以减少昂贵的磁盘I/O? <h5>五、优化查?/h5> 很多人查询都是在查一LQ完全可以用反向代理合ƈq些q发的相同的查询。这L技术主要用查询l果~存来实玎ͼW一ơ查询走数据库获得数据，q把 数据攑ֈ~存Q后面的查询l统直接讉K高速缓存。ؓ每个查询做HashQ用NoSQL的技术可以完成这个优化。（q个技术也可以用做静态页面） 对于火R量的查询，个h觉得不要昄数字Q就昄一?#8220;?#8221;?#8220;?#8221;好了，q样可以大大化系l复杂度Qƈ提升性能? <h5>六、缓存的问题</h5> ~存可以用来~存动态页面，也可以用来缓存查询的数据。缓存通常有那么几个问题： 1Q缓存的更新。也叫缓存和数据库的同步。有q么几种ҎQ一是缓存time outQ让~存失效Q重查，二是Q由后端通知更新Q一量后端发生变化，通知前端更新。前者实现v来比较简单，但实时性不高，后者实现v来比较复?Q但实时性高? 2Q缓存的换页。内存可能不够，所以，需要把一些不z跃的数据换出内存，q个和操作系l的内存换页和交换内存很怼。FIFO、LRU、LFU都是比较l典的换늮法。相兛_容参?a target="_blank">Wikipeida的缓存算?/a>? 3Q缓存的重徏和持久化。缓存在内存Q系l总要l护Q所以，~存׃丢失Q如果缓存没了，需要重建，如果数据量很大，~存重徏的过E会很慢Q这会媄响生产环境，所以，~存的持久化也是需要考虑的? 诸多强大的NoSQL都很好支持了上述三大~存的问题? <h4>后端性能优化技?/h4> 前面讨论了前端性能的优化技术，于是前端可能׃是瓶颈问题了。那么性能问题׃到后端数据上来了。下面说几个后端常见的性能优化技术? <h5>一、数据冗?/h5> 关于数据冗余Q也是_把我们的数据库的数据冗余处理Q也是减少表连接这L开销比较大的操作Q但q样会牺牲数据的一致性。风险比较大。很多h 把NoSQL用做数据Q快是快了，因ؓ数据冗余了，但这Ҏ据一致性有大的风险。这需要根据不同的业务q行分析和处理。（注意Q用关系型数据库很容易移?到NoSQL上，但是反过来从NoSQL到关pd难了） <h5>二、数据镜?/h5> 几乎所有主的数据库都支持镜像Q也是replication。数据库的镜像带来的好处是可以做负载均衡。把一台数据库的负载均分到多台上，同时又保证了数据一致性（Oracle的SCNQ。最重要的是Q这栯可以有高可用性，一台废了，q有另一台在服务? 数据镜像的数据一致性可能是个问题，所以我们要吧在单条数据上进行数据分区，也就是说Q把一个畅销商品的库存均分到不同的服务器上，如，一个畅销商品?万的库存Q我们可以设|?0台服务器Q每台服务器上有100个库存，q就好像B2C的仓库一栗? <h5>三、数据分?/h5> 数据镜像不能解决的一个问题就是数据表里的记录太多Q导致数据库操作太慢。所以，把数据分区。数据分区有很多U做法，一般来说有下面q几U： <br /> <br /> 1Q把数据把某U逻辑来分cR比如火车票的订系l可以按各铁路局来分Q可按各UR型分Q可以按始发站分Q可以按目的地分……Q反正就是把一张表拆成多张有一L字段但是不同U类的表Q这Pq些表就可以存在不同的机器上以达到分担负载的目的? <br /> <br /> 2Q把数据按字D分Q也是坚着分表。比如把一些不l常改的数据攑֜一个表里，l常改的数据攑֜另一个表里。把一张表变成1?的关p，q样Q你?以减表的字D个敎ͼ同样可以提升一定的性能。另外，字段多会造成一条记录的存储会被攑ֈ不同的页表里Q这对于d性能都有问题? <br /> <br /> 3Q^均分表。因为第一U方法是q不一定^均分均，可能某个U类的数据还是很多。所以，也有采用q_分配的方式，通过主键ID的范围来分表? <br /> <br /> 4Q同一数据分区。这个在上面数据镜像提过。也是把同一商品的库存值分C同的服务器上Q比如有10000个库存，可以分到10台服务器上，一C?000个库存。然后负载均衡? q三U分区都有好有坏。最常用的还是第一U。数据一量分区，你就需要有一个或是多个调度来让你的前端程序知道去哪里找数据?strong>把火车票的数据分区，q放在各个省市，会对12306q个pȝ有非常有意义的质的性能的提?/strong>? <h5>四、后端系l负载均?/h5> 前面说了数据分区Q数据分区可以在一定程度上减轻负蝲Q但是无法减ȝ销商品的负载，对于火R来_可以认ؓ是大城市的某些主q线上的车票。这?需要用数据镜像来减轻负蝲。用数据镜像，你必然要使用负蝲均衡Q在后端Q我们可能很难用像路由器上的负载均衡器Q因为那是均衡流量的Q因为流量ƈ?代表服务器的J忙E序。因此，我们需要一个Q务分配系l，其还能监控各个服务器的负载情c? d分配服务器有一些难点： <ul> <li>负蝲情况比较复杂。什么叫忙？是CPU高？q是盘I/O高？q是内存使用高？q是q发高？你可能需要全部都要考虑。这些信息要发送给那个d分配器上Q由d分配器挑选一台负载最ȝ服务器来处理?/li> </ul> <ul> <li>d分配服务器上需要对d队列Q不能丢d啊，所以还需要持久化。ƈ且可以以扚w的方式把d分配l计服务器?/li> </ul> <ul> <li>d分配服务器死了怎么办？q里需要一些如Live-Standby或是failover{高可用性的技术。我们还需要注意那些持久化了的d的队列如果{Ud别的服务器上的问题?/li> </ul> 我看到有很多pȝ都用静态的方式来分配，有的用hashQ有的就单地轮流分析。这些都不够好，一个是不能完美地负载均衡，另一个静态的Ҏ的致命缺hQ如果有一台计服务器L了，或是我们需要加入新的服务器Q对于我们的分配器来_都需要知道? q有一U方法是使用抢占式的方式q行负蝲均衡Q由下游的计服务器MQ务服务器上拿d。让q些计算服务器自己决定自己是否要d。这L好处是可 以简化系l的复杂度，而且q可以Q意实时地减少或增加计服务器。但是唯一不好的就是，如果有一些Q务只能在某种服务器上处理Q这可能会引入一些复杂度?不过M来说Q这U方法可能是比较好的负蝲均衡? <h5>五、异步?throttle ?扚w处理</h5> 异步、throttleQ节阀Q?和批量处理都需要对q发h数做队列处理的? <ul> <li>异步在业务上一般来说就是收集请求，然后延时处理。在技术上是可以把各个处理程序做成ƈ行的Q也可以水qx展了。但是异步的技术问题大概有 q?些，aQ被调用方的l果q回Q会涉及q程U程间通信的问题。bQ如果程序需要回滚，回滚会有点复杂。cQ异步通常都会伴随多线E多q程Qƈ发的控制也相?ȝ一些。dQ很多异步系l都用消息机Ӟ消息的丢失和乱序也会是比较复杂的问题?/li> </ul> <ul> <li>throttle 技术其实ƈ不提升性能Q这个技术主要是防止pȝ被超q自׃能处理的量l搞垮了Q这其实是个保护机制。用throttle技术一般来说是对于一些自己无法控制的pȝQ比如，和你|站Ҏ的银行系l?/li> </ul> <ul> <li>扚w处理的技术，是把一堆基本相同的h扚w处理。比如，大家同时购买同一个商品，没有必要你买一个我写一ơ数据库Q完全可以收集到一定数??hQ一ơ操作。这个技术可以用作很多方面。比如节省网l带宽，我们都知道网l上的MTUQ最大传输单元）Q以态网?500字节Q光U可以达?000 多个字节Q如果你的一个网l包没有放满q个MTUQ那是在浪费网l带宽，因ؓ|卡的驱动程序只有一块一块地L率才会高。因此，|络发包Ӟ我们需要收 集到_多的信息后再做网lI/OQ这也是一U批量处理的方式。批量处理的敌h是流量低Q所以，扚w处理的系l一般都会设|上两个阀|一个是作业量，?一个是timeoutQ只要有一个条件满I׃开始提交处理?/li> </ul> 所以，<strong>只要是异步，一般都会有throttle机制Q一般都会有队列来排队，有队列，׃有持久化Q而系l一般都会用批量的方式来处?/strong>? <a target="_blank">云风同学设计?#8220;排队pȝ”</a> 是q个技术。这和电子商务的订单pȝ很相|是_我的pȝ收到了你的购下单请求，但是我还没有真正处理Q我的系l会跟据我自q处理能力来throttle住这些大量的hQƈ一点一点地处理。一旦处理完成，我就可以发邮件或短信告诉用户你来可以真正购票了? <br /> <br /> 在这里，我想通过业务和用户需求方面讨Z下云风同学的q个排队pȝQ因为其从技术上看似解决了这个问题，但是从业务和用户需求上来说可能q是有一些值得我们L入思考的地方Q? <br /> <br /> 1Q?strong>队列的DoSd</strong>。首先，我们思考一下，q个?是个单纯地排队的吗？q样做还不够好，因ؓq样我们不能杜绝黄牛Q而且单纯的ticket_id很容易发生DoSdQ比如，我发起N?ticket_idQ进入购流E后Q我不买Q我p你半个时Q很Ҏ我就可以让想买票的h几天都买不到。有Q用户应该要用n份证来排队， q样在购买里必需要用q个w䆾证来乎ͼ但这也还不能杜绝黄牛排队或是可子。因Z们可以注册N个帐h排队Q但是不买。黄牛这些hq个时候只需要干 一个事Q把|站搞得正常不能讉KQ让用户只能通过他们来买? <br /> <br /> 2Q?strong>对列的一致?/strong>Q对q个队列的操作是不是需要锁Q只要有锁，性能一定上不去。试惻I100万个人同时要求你来分配位|号Q这个队列将会成为性能瓉。你一定没有数据库实现得性能好，所以，可能比现在还? <br /> <br /> 3Q?strong>队列的等待时?/strong>。购时间半时够不够？多不 多？要是那时用户正好不能上网呢？如果旉短了Q用户也会抱怨，如果旉长了Q后面在排队的那些h也会抱怨。这个方法可能在实际操作上会有很多问题。另 外，半个时太长了，q完全不现实Q我们用15分钟来D例：?千万用户Q每一个时d能放q去1万个Q这1万个用户需?5分钟完成所有操作，那么Q这 1千万用户全部处理完，需?000*15m = 250时Q?0天半Q火车早开了。（我ƈpQ?a target="_blank">Ҏ铁道部专家的说明</a>Q这几天Q^均一天下?00万，所以，处理1000万的用户需要十天。这个计可能有点简单了Q我只是惌Q?strong>在这样低负蝲的系l下用排队可能都不能解决问题</strong>Q? <br /> <br /> 4Q?strong>队列的分分式</strong>。这个排队系l只有一个队列好吗？ q不_好。因为，如果你放q去的可以购的人如果在买同一个Rơ的同样的类型的（比如某动车卧铺）Q还是等于在抢票Q也是说系l的负蝲q是会有可能 集中到其中某台服务器上。因此，最好的Ҏ是根据用L需?#8212;—提供出发地和目的圎ͼ来对用户q行排队。而这样一来，队列也就可以是多个，只要是多个队 列，可以水qx展了? 我觉得完全可以向|上购物学习。在排队Q下单）的时候，攉好用L信息和想要买的票Qƈ允许用户讄购票的优先Q比如，A车次卧铺?不到׃ B车次的卧铺，如果q买不到׃{等Q然后用h所需的钱先充值好Q接下来是pȝ完全自动地异步处理订单。成功不成功都发短信或邮仉知用户。这 Ppȝ不仅可以省去那半个小时的用户交互旉Q自动化加快处理Q还可以合ƈ相同购票h的hQ进行批处理Q减数据库的操作次敎ͼ。这U方法最妙的事是 可以知道q些排队用户的需求，不但可以优化用户的队列，把用户分布到不同的队列，q可以像亚马逊的心愿单一P让铁道部做Rơ统{安排和调整Q最后，排队 pȝQ下单系l）q是要保存在数据库里的或做持久化Q不能只攑֜内存中，不然机器一downQ就{着被骂吧）? <h4>结</h4> 写了那么多，我小l一下： <br /> 0Q无Z怎么设计Q你的系l一定要能容易地水^扩展。也是_你的整个数据中Q所有的环节都要能够水^扩展。这P当你的系l有性能问题Ӟ“?倍的服务?#8221;才不会被W? <br /> <br /> 1Q上q的技术不是一朝一夕能搞定的，没有长期的积累，基本无望? <br /> <br /> 2Q集中式的卖很难搞定，使用上述的技术可以让订票pȝ能有几䘪倍的性能提升。而在各个省市建分站，分开卖票Q是能让现有pȝ性能有质的提升的最好方法? <br /> <br /> 3Q春q前夕抢且量供远于求这U业务模式是相当变态的Q让几千万甚至上亿的人在某个早晨?炚w同时d同时抢票的这U业务模式是变态中的变态。业务Ş态的变态决定了无论他们怎么办干一定会被骂? <br /> <br /> 4Qؓ了那么一两个星期而搞那么大的pȝQ而其它时间都在闲着Q也是铁\才干得出来这L事了? </div><img src ="http://m.tkk7.com/paulwong/aggbug/368659.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://m.tkk7.com/paulwong/" target="_blank">paulwong</a> 2012-01-17 15:23 <a href="http://m.tkk7.com/paulwong/archive/2012/01/17/368659.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>铁\的售系l来说明分库分表Ҏ构的影响http://m.tkk7.com/paulwong/archive/2012/01/17/368653.htmlpaulwongpaulwongTue, 17 Jan 2012 05:24:00 GMThttp://m.tkk7.com/paulwong/archive/2012/01/17/368653.htmlhttp://m.tkk7.com/paulwong/comments/368653.htmlhttp://m.tkk7.com/paulwong/archive/2012/01/17/368653.html#Feedback0http://m.tkk7.com/paulwong/comments/commentRss/368653.htmlhttp://m.tkk7.com/paulwong/services/trackbacks/368653.html
不是。因为数据量不大Q真不大?br />
每一个Rơ与车次间是独立的，每Rơ不过2000张票Q一天发车不过50万Rơ；
以预售期15天来Ԍ15*0.1亿张不超q?.5亿笔的热U数据，UC上v量数据的?br /> 再加上可以按U\分库Q更是不到千万的单表容量。已l发车完成的q入归分析?br /> x据库按\U用不同的服务器，不同的Rơ放在不同的表中。ƈ发量锁真不大?br />
当然Q如果不分库分表Q再加上不归档处理，铁\的售系l的数据量看h是v量的Q?br />关键是这量的数据没有意义?br />

二、如何分库分表？

2.1 分库Q考虑数据间没有直接关pd服务器如何部|?br />
铁\的售系lؓ例来_按\U分库，再按车次分表是合理的?br /> 设\U有1万条Q按?000条需要两台服务器(一台热机沉?Q不?0台服务器
如果使用SAN存储Q则使用SAN作ؓ存储Q本Z为热机沉余，只需?0台?br /> 当然使用mySQLq种l济型数据库Q服务器需要更多来防灾Q?br /> 卛_以采用双写或多写的方式来保证数据的绝对安全?br />
2.2分表Q考虑数据间不存在重叠Q即数据满二分原则

铁\的售系l的L两个车次是没有关pȝQ所以可以分表?br /> 电信的某个用L通话和其它用L通话记录Q也是没有关p，所以可以分表处?br /> Q实际上电信的系l，分库分表后也是不大的Q难在后台的计费、结等规则Q?br />


三、数据库讉K接口



1. 元数据：如何识别到当前要处理的数量在哪张表？

铁\的售系l会有一个Rơ管理系l，?012q??2?D3206 车次Q?br /> 按预先设计的在哪台服务器的哪个库Q徏哪个表?br />
2.建立元数据的规则Q即具体如何分库分表的规?br />
q个是数据库的讉K接口?br />
3.数据库访问接口的透明E度

卛_个层知道哪些元数据信息?br /> 例，是否让窗口售的客户端来解析元数据的规则然后~存Q还是通过中间件来解析~存?br />
具体各层使用怎样透明E度Q和业务性质、节点和数据中心的拓扑等有关?br />


四、历史数据归与分析

1.使用分库分表后，数据需要归，分析处理的程序变得复杂，但联机交易变得?br /> 2.分析Q要注意是针对热U数据分析、归档数据分析、؜合分析有养I
通过分库分表和归档，更方便用分布式的统计方案?br />
具体可以参考，淘宝的开攑^台架构师写的文章Q?br />
l论Q分库分表跟不分库分表，整个架构是完全不一L?br />
像铁的售票pȝ、淘宝、电信、银行等Q绝对要采用分库分表的数据存储方案，

来解x据量的增长而不影响性能的问题?br />
像淘宝等互联|应用还要解军_宽即CDN问题?img src ="http://m.tkk7.com/paulwong/aggbug/368653.html" width = "1" height = "1" />

paulwong 2012-01-17 13:24 发表评论
]]> վ֩ģ壺 18ڵվ| ۺ| Aһ AƵһ | Ʒһ | aŹavۺav| 99߹ۿ| պһ| Ļ| ޾ƷԲ߹ۿ| ɫžžþWWWۺ| ƷƵ| ҹƵ| ͩרĻ| һ| պƷһ| þþþþྫƷֱ| ˵ĺѹۿƵ| ޾Ʒר91| a߹a| ҹƬAVƬ| Ʒѹۿ| ɫƵ߹ۿ| ޾ƷƬ߹ۿ| ѿƵijAPP| þþƷ77777| Ƶ77777| ˳վ| þۺɫHEZYO| 97޾ƷȫƵ| ޵һƵ߹ۿ| Ů18Ƶ| ʪһҹƷѸ| ҵС身߿Ѹ| ޾Ʒ| ˳Ƶ| ޳AVƬ߹ۿ| ɫƬѹۿ| һػaѴƬ| ˳Ƶ| һa뼺Ӳִѿ51Ʒ | þAëƬѹۿ|