亚洲av成人无遮挡网站在线观看,少妇性bbb搡bbb爽爽爽,亚洲av日韩精品久久久久久,兔费看少妇性l交大片免费,无码少妇一区二区三区

Chinaunix

標題: [討論]電子商務(wù)/電子廣告/游戲網(wǎng)站中常用的MySQL架構(gòu)（獲獎名單已公布） [打印本頁]

作者: yuhongchun 時間: 2012-03-20 14:47
提示: 作者被禁止或刪除內(nèi)容自動屏蔽

作者: send_linux 時間: 2012-03-20 15:17
支持一下，床單好東西.....

作者: expert1 時間: 2012-03-20 15:20

正好我的床單破了，送一份唄。哈哈

作者: 小版主殺手 時間: 2012-03-20 15:22
支持
1.生產(chǎn)環(huán)境中一般用的主從就差不多了，最好避免主從跨機房，版本可以用5.1以上的，5.5的對對多線程的支持很好，多CPU也是一樣
2.讀寫分離，個人覺得通過程序端控制還不錯
3.能夠使用memcached是不錯的主意，某些業(yè)務(wù)不合適的話用內(nèi)存表代替緩存也可行

一般，mysl架構(gòu)一定要結(jié)合業(yè)務(wù)來分析、設(shè)計、優(yōu)化

瞎扯了幾句哈哈

作者: 無風之谷 時間: 2012-03-20 15:27
換換口味，床單好啊，必備佳品，大家多多參與，多多分享干貨~！

作者: chenyx 時間: 2012-03-20 15:28

我們究竟應(yīng)該如何設(shè)計自己的MySQL高可用架構(gòu)，保證企業(yè)網(wǎng)站或系統(tǒng)如何穩(wěn)定的運行呢？面對幾億次查詢/日的SQL查詢，我們究竟應(yīng)該如何優(yōu)化我們的MySQL數(shù)據(jù)庫架構(gòu)來達到用戶的正常應(yīng)常訪問呢？

還沒有研究過如此大規(guī)模的并發(fā)數(shù)據(jù)庫的問題呢.
個人認為,如此大的數(shù)據(jù)庫訪問,普通的主從數(shù)據(jù)庫模式應(yīng)該很難有大的提升,既然是要求高可用的架構(gòu),那么數(shù)據(jù)庫也應(yīng)該是高可用的,涉及到高可用,那么集群架構(gòu)就一定是首選.
前一段時間Mysql的Cluster版本不是也更新了嗎,mysql應(yīng)該也是意識到性能瓶頸了吧

作者: ruochen 時間: 2012-03-20 15:28

expert1 發(fā)表于 2012-03-20 15:20
正好我的床單破了，送一份唄。哈哈

赤裸裸的需求啊

作者: yuhongchun 時間: 2012-03-20 15:30
提示: 作者被禁止或刪除內(nèi)容自動屏蔽

作者: Gray1982 時間: 2012-03-20 15:31
大力的支持

1，一般情況下，Mysql在企業(yè)中的主從方案是常見的，只不過是一主一從還是一主多從的方案。在設(shè)計表的時候，一般情況下，從機起備份查詢的作用，所以表引擎為MYISAM居多。
2，讀寫分離的一般都是自己寫程序
3，至于用memcache還是redis看情況需要吧，有可能需要的數(shù)據(jù)完整性，速度不同，熱備機制不同。

作者: 小版主殺手 時間: 2012-03-20 15:32

chenyx 發(fā)表于 2012-03-20 15:28
還沒有研究過如此大規(guī)模的并發(fā)數(shù)據(jù)庫的問題呢.
個人認為,如此大的數(shù)據(jù)庫訪問,普通的主從數(shù)據(jù)庫模式應(yīng)該很 ...

mysql cluster集群在生產(chǎn)環(huán)境核心環(huán)節(jié)上估計用的很少

作者: yuhongchun 時間: 2012-03-20 15:34
提示: 作者被禁止或刪除內(nèi)容自動屏蔽

作者: yuhongchun 時間: 2012-03-20 15:35
提示: 作者被禁止或刪除內(nèi)容自動屏蔽

作者: ruochen 時間: 2012-03-20 15:36
目前我們開始準備在webgame行業(yè)啟用redis+mysql的嘗試方案
游戲中的：好友關(guān)系、排行榜、計數(shù)器、隊列、cache都很適合通過redis來實現(xiàn)

至于redis的事務(wù)功能，問了一些圈內(nèi)的朋友，好像都沒有關(guān)心的

作者: chenyx 時間: 2012-03-20 15:36
回復 10# 小版主殺手

高可用不用群集,那么怎么設(shè)計架構(gòu)呢? mysql的群集還沒用過呢,不知道在生產(chǎn)環(huán)境下用的是什么
單純的讀寫分離,主從架構(gòu),能經(jīng)受住上億的數(shù)據(jù)庫請求嗎,有點懷疑.
記得很久前有一個討論php的文章,程序的速度遠遠快于數(shù)據(jù)庫的數(shù)據(jù)返回速度,應(yīng)用的瓶頸在數(shù)據(jù)庫上面.

作者: chenyx 時間: 2012-03-20 15:39
回復 11# yuhongchun

撫琴,如果不用mysql Cluster,那么單純的主從/讀寫分離在生產(chǎn)環(huán)境下,能經(jīng)受的數(shù)據(jù)庫訪問數(shù)量,你測試的最大值是多少?

作者: ruochen 時間: 2012-03-20 15:41
本帖最后由 ruochen 于 2012-03-20 15:43 編輯

yuhongchun 發(fā)表于 2012-03-20 15:35
基本沒見過。

國內(nèi)有很少的案例

另外提一點：cluster的成本（大部分是維護成本）還是比較高的
相信隨著cluster 7.2（內(nèi)嵌mc）的性能提升以及后續(xù)版本的發(fā)布，估計案例會越來越多，畢竟是非常好的sharding-nothing的方案

大多數(shù)的場合，一般在應(yīng)用層做讀、寫分離，然后mysql通過復制來實現(xiàn)，優(yōu)點比較多，可控性非常好

作者: 小版主殺手 時間: 2012-03-20 15:48

chenyx 發(fā)表于 2012-03-20 15:36
回復 10# 小版主殺手

過億的請求這種需求比較少，這時候就可以考慮從業(yè)務(wù)上來拆分了

作者: 小版主殺手 時間: 2012-03-20 15:50
每個數(shù)據(jù)庫都有各自的優(yōu)點，看業(yè)務(wù)，數(shù)據(jù)量真是海量的話，就要考慮其他數(shù)據(jù)庫
做數(shù)據(jù)庫擅長做的，才是最大化的運用數(shù)據(jù)庫

作者: yuhongchun 時間: 2012-03-20 15:52
提示: 作者被禁止或刪除內(nèi)容自動屏蔽

作者: yuhongchun 時間: 2012-03-20 15:53
提示: 作者被禁止或刪除內(nèi)容自動屏蔽

作者: king_819 時間: 2012-03-20 16:21

小版主殺手發(fā)表于 2012-03-20 15:32
mysql cluster集群在生產(chǎn)環(huán)境核心環(huán)節(jié)上估計用的很少

mysql cluster集群感覺不太成熟，沒有實際的案例，也沒人敢冒險，還是有待改進吧

作者: king_819 時間: 2012-03-20 16:26
回復 13# ruochen

我們最近在試用Hbase

作者: king_819 時間: 2012-03-20 16:30
回復 14# chenyx

一般都是進行業(yè)務(wù)切分，前端緩存、分庫分表

作者: yuhongchun 時間: 2012-03-20 17:35
提示: 作者被禁止或刪除內(nèi)容自動屏蔽

作者: 4nianyici 時間: 2012-03-20 18:01
回復 1# yuhongchun

不錯的活動，支持，尤其是那床單三件套是必備品啊，很不錯

作者: king_819 時間: 2012-03-20 18:50

yuhongchun 發(fā)表于 2012-03-20 17:35
測試了很多一段時間MySQL Proxy0.8.2，感覺上生產(chǎn)環(huán)境還是有些不放心。。

可以試用一下Amoeba

作者: 老男孩linux培訓 時間: 2012-03-20 22:56
回復 4# 小版主殺手

贊一個，有道理。但還是保守了點。大公司跨機房同步也是常有的。

作者: kqzj 時間: 2012-03-21 08:33
主庫單點怎么解決？

作者: vermouth 時間: 2012-03-21 09:18
回復 28# 老男孩linux培訓

大公司一般都有專線吧

作者: yuhongchun 時間: 2012-03-21 09:36
提示: 作者被禁止或刪除內(nèi)容自動屏蔽

作者: yuhongchun 時間: 2012-03-21 09:37
提示: 作者被禁止或刪除內(nèi)容自動屏蔽

作者: zfdream101 時間: 2012-03-21 09:38
學習一下，雖然不太懂

作者: yuhongchun 時間: 2012-03-21 09:39
提示: 作者被禁止或刪除內(nèi)容自動屏蔽

作者: dengbao2001 時間: 2012-03-21 10:57
好獎品呀，準備換床單了！

說實施，我從沒用過MYSQL，所以在這里等待大家發(fā)言共享自己的經(jīng)驗了

作者: hero0524 時間: 2012-03-21 11:47
本帖最后由 hero0524 于 2012-03-21 11:48 編輯

活動幾月幾號在哪個城市以什么方式舉辦？
收不收費？
到時候一定要通知我哦！��！
178572787@qq.com

作者: ooooldman 時間: 2012-03-21 11:58
話題1：生產(chǎn)環(huán)境下的MySQL架構(gòu)方案
話題2: MySQL讀寫分離的實現(xiàn)方式
話題3: MySQL結(jié)合memcached、redis的架構(gòu)方案

1，生產(chǎn)中我接觸的幾家電子商務(wù)都是主從架構(gòu)，然后用drbd +ha做的master 備份，
2，基本上都是在程序上實現(xiàn)的，我曾經(jīng)接觸一個項目，因為時間的原故，不可能吧程序抽出來做分離，后來用mysql-proxy來做，咨詢了一下lua腳本的高手，給弄了個腳本，生產(chǎn)環(huán)境中表現(xiàn)的也不錯的，至于amoeba的話，不支持事務(wù)，因為是電子商務(wù)，所以當時沒考慮
3，用的memcache

作者: ruochen 時間: 2012-03-21 12:47

yuhongchun 發(fā)表于 2012-03-21 09:37
DRBD+Heartbeat+MySQL，利用雙機來解決Master單點的問題，這是一種策略；其實更多時候，是利用slave來取 ...

這個方案的“腦裂”問題需考慮

作者: ruochen 時間: 2012-03-21 12:49

king_819 發(fā)表于 2012-03-21 10:09
回復 30# vermouth

一般還是需要專線的，天朝的網(wǎng)絡(luò)大家都懂的

作者: 楓影誰用了 時間: 2012-03-21 14:36
話題1：生產(chǎn)環(huán)境下的MySQL架構(gòu)方案
就目前現(xiàn)狀而言，主要還是主從或主主(偽主主配置成主主模式，實際使用的只有一邊)，一般擴展的都是通過模塊業(yè)務(wù)分離，分出多個物理服務(wù)器。
再細一些就是分表分區(qū)。
另外一個就是MySQL  NDB，這是一種非�？孔V的方案，只是前期投入的硬件成本(相對于主從)較高，一般的小項目不會使用。結(jié)合lvs就是一個完美的方案，但是開發(fā)過程中需要避免NDB的種種限制。目前主流的思想是說這個不成熟，不用、不測試你怎么知道不成熟呢？
還有一種是MySQL 官方推薦的drbd，這個在做風險容災(zāi)的時候有一定作用，但不能起到擴展......

最后一個難搞的是全國多機房部署的話，以上架構(gòu)也是顯得相當吃力的，都需要在應(yīng)用層相當大的配合。所以不管是那種架構(gòu)，根據(jù)業(yè)務(wù)要求組合成符合需求的即是最好的，不能泛泛而談。

話題2:  MySQL讀寫分離的實現(xiàn)方式
mysql-proxy,這個懂lua語言的還是有相當?shù)膬?yōu)勢的，把事務(wù)處理及監(jiān)控做好，也是強烈推薦的
其次是在應(yīng)用層來處理此類事情，應(yīng)該根據(jù)標識選擇相應(yīng)的連接池。
amoeba看過資料，沒用過。

話題3:  MySQL結(jié)合memcached、redis的架構(gòu)方案
說到這個又不得不來看看mysql ndb 7.2 memcached 的api，也是一個相當完善的方案。http://www.mysql.com/why-mysql/w ... cluster-7.2-ga.html
至于mysql 結(jié)合memcached，一般的小數(shù)據(jù)或靜態(tài)數(shù)據(jù)用sql自己的cache已經(jīng)相當不錯。
也看到過有好些將mysql 數(shù)據(jù)映射到memcache上去的，至于效果如何沒使用過。

作者: long904 時間: 2012-03-21 15:05

ruochen 發(fā)表于 2012-03-21 12:49
一般還是需要專線的，天朝的網(wǎng)絡(luò)大家都懂的

倘若還無條件建專線�？鐧C房的同步是否只能用rsync類了？

作者: king_819 時間: 2012-03-21 15:06
回復 40# ruochen

不讓drbd 自啟動，進行手動切換

作者: yuhongchun 時間: 2012-03-21 15:32
提示: 作者被禁止或刪除內(nèi)容自動屏蔽

作者: yuhongchun 時間: 2012-03-21 15:33
提示: 作者被禁止或刪除內(nèi)容自動屏蔽

作者: ruochen 時間: 2012-03-21 17:12

楓影誰用了發(fā)表于 2012-03-21 14:36
話題1：生產(chǎn)環(huán)境下的MySQL架構(gòu)方案
就目前現(xiàn)狀而言，主要還是主從或主主(偽主主配置成主主模式，實際使用 ...

有時間分享下你的NDB經(jīng)驗吧

作者: expert1 時間: 2012-03-21 18:35
拆分唄，這個從業(yè)務(wù)和程序來規(guī)劃

緩存，地球人都知道

m/s同步

單點的情況，切換唄，沒辦法。

市面上能看到都這幾個情況唄。沒啥談的。

真正復雜的，自己開發(fā)代碼，解決不同idc之間同步的情況，這個少數(shù)公司才有這個實力。

作者: expert1 時間: 2012-03-21 18:35
ps,床單到手了吧？

作者: 楓影誰用了 時間: 2012-03-22 09:03

ruochen 發(fā)表于 2012-03-20 15:36
目前我們開始準備在webgame行業(yè)啟用redis+mysql的嘗試方案
游戲中的：好友關(guān)系、排行榜、計數(shù)器、隊列、ca ...

其實最終就是從關(guān)系型數(shù)據(jù)中解脫出來以發(fā)揮最大的性能？

作者: 楓影誰用了 時間: 2012-03-22 09:06

chenyx 發(fā)表于 2012-03-20 15:36
回復 10# 小版主殺手

所以現(xiàn)在一般普通的做法就是分解再分解。分成N個層，N個庫，N個表，N個區(qū)。

作者: chenyx 時間: 2012-03-22 09:08
回復 53# 楓影誰用了

也就是說數(shù)據(jù)庫拆分,放到不同的服務(wù)器上,然后一次查詢,分別在不同的服務(wù)器上獲取數(shù)據(jù)?
這樣的話,高可用怎么保證?

作者: renxiao2003 時間: 2012-03-22 10:03
我想問一下，生產(chǎn)環(huán)境下的MYSQL集群是采用什么方式搭建的？主機要不要使用集群？
如何測試并發(fā)訪問的承載？

作者: Gray1982 時間: 2012-03-22 10:06

ruochen 發(fā)表于 2012-03-20 15:41
國內(nèi)有很少的案例

另外提一點：cluster的成本（大部分是維護成本）還是比較高的

在訪問量不大的情況下，cluster的效率不如主從
訪問量很大的情況下，因為可以多臺mysql server共同處理，所以會快很多
不過，確實現(xiàn)在cluster用的比較少

作者: Gray1982 時間: 2012-03-22 10:09

king_819 發(fā)表于 2012-03-20 16:26
回復 13# ruochen

HBASE好像不如REDIS哦，在效率方面。
曾經(jīng)用Hadoop實驗過，HBASE比較慢，也有可能是應(yīng)用方面不同
看你結(jié)果。

作者: Gray1982 時間: 2012-03-22 10:13

king_819 發(fā)表于 2012-03-21 15:06
回復 40# ruochen

這個也是可以自動的，只是寫個sleep就可以了，沒問題滴

作者: Gray1982 時間: 2012-03-22 10:17

chenyx 發(fā)表于 2012-03-22 09:08
回復 53# 楓影誰用了

不同的物理文件放在不同的物理硬盤上
或者
不同的服務(wù)放在不同的服務(wù)器上

還是說，如果訪問量不大，主從
訪問量比較大的時候，cluster和proxy還是可以突顯出來的

作者: 楓影誰用了 時間: 2012-03-22 11:15
回復 54# chenyx

master+master
drbd
以上再配合上自動化監(jiān)控處理工具。

作者: king_819 時間: 2012-03-22 12:01
回復 58# Gray1982

通過對freebsd的內(nèi)核進行優(yōu)化后，性能也是很強大的

作者: ruochen 時間: 2012-03-22 12:14

楓影誰用了發(fā)表于 2012-03-22 09:03
其實最終就是從關(guān)系型數(shù)據(jù)中解脫出來以發(fā)揮最大的性能？

這些功能一般都是游戲中大多都有的，想找個通用的工具，并且也具備MC的cache功能

作者: Gray1982 時間: 2012-03-22 14:20

king_819 發(fā)表于 2012-03-22 12:01
回復 58# Gray1982

BSD系統(tǒng)本身的性能就會比Linux好一些
其實Linux從內(nèi)核到各種參數(shù)的修改，配合起來，性能也是不錯的，當然是和沒做過優(yōu)化的對比。

作者: Gray1982 時間: 2012-03-22 14:22

ruochen 發(fā)表于 2012-03-22 12:14
這些功能一般都是游戲中大多都有的，想找個通用的工具，并且也具備MC的cache功能

具備MC的cache功能的應(yīng)該很多吧
主要是看要cache多少東西，cache的內(nèi)容是什么，是不是允許丟失數(shù)據(jù)
一般的開源cache是可以滿足的

作者: 無風之谷 時間: 2012-03-22 14:34
呵呵大家有沒有實際的案例拿出來分享一下嘛

作者: 無風之谷 時間: 2012-03-22 14:35
回復 44# king_819

案例最好能直接貼過來

作者: yuhongchun 時間: 2012-03-22 14:57
提示: 作者被禁止或刪除內(nèi)容自動屏蔽

作者: 北極熊和企鵝 時間: 2012-03-22 15:10
支持下。呵呵

作者: send_linux 時間: 2012-03-22 18:25

king_819 發(fā)表于 2012-03-22 12:01
回復 58# Gray1982

CU以前大部分機器都是FreeBSD的，連MySQL都跑在上面，碎說性能不是很高......

現(xiàn)在基本上都遷到CentOS上了

作者: 楓影誰用了 時間: 2012-03-22 19:08

send_linux 發(fā)表于 2012-03-22 18:25
CU以前大部分機器都是FreeBSD的，連MySQL都跑在上面，碎說性能不是很高......

現(xiàn)在基本上都遷到Cent ...

話說當年確實是如此。。

http://people.fsn.hu/~bra/freebs ... HuangMysqlbench.pdf

作者: send_linux 時間: 2012-03-22 19:30

楓影誰用了發(fā)表于 2012-03-22 19:08
話說當年確實是如此。。

http://people.fsn.hu/~bra/freebs ... 2-16/LeoHuangMysqlb ...

可能是現(xiàn)在公司為了方便統(tǒng)一管理吧

不知道現(xiàn)在還有哪些大的公司在大量部署和使用FreeBSD��？

作者: 老男孩linux培訓 時間: 2012-03-22 19:56
回復 13# ruochen

已經(jīng)不是新鮮事了。用的比較普遍了。

作者: crulat 時間: 2012-03-22 21:06
回復 75# 老男孩linux培訓

不錯，支持！

作者: kns1024wh 時間: 2012-03-22 21:33
回復 1# yuhongchun

搞個實際的話語

2T的混合存儲引擎的安全、備份、優(yōu)化

作者: chenyx 時間: 2012-03-22 22:14
回復 75# 老男孩linux培訓

圖很復雜,看著眼暈

db調(diào)度器用什么實現(xiàn)呢?

作者: yuhongchun 時間: 2012-03-23 09:12
提示: 作者被禁止或刪除內(nèi)容自動屏蔽

作者: chenyx 時間: 2012-03-23 09:15
回復 79# yuhongchun

lvs,原來一直以為lvs做負載均衡的,看來out了.

作者: chenyx 時間: 2012-03-23 09:19
回復 75# 老男孩linux培訓

老男孩來個調(diào)度器+DBn群組的配置實例怎么樣?

作者: yuhongchun 時間: 2012-03-23 09:19
提示: 作者被禁止或刪除內(nèi)容自動屏蔽

作者: chenyx 時間: 2012-03-23 09:20
嗯,Keepalived做熱備.

作者: yuhongchun 時間: 2012-03-23 09:38
提示: 作者被禁止或刪除內(nèi)容自動屏蔽

作者: wlforyou1 時間: 2012-03-23 09:57
讀寫分離是怎么實現(xiàn)的哇

作者: yuhongchun 時間: 2012-03-23 10:05
提示: 作者被禁止或刪除內(nèi)容自動屏蔽

作者: wlforyou1 時間: 2012-03-23 10:13
回復 87# yuhongchun

好深奧啊。我怎么才能搞會啊。唉

作者: realmon 時間: 2012-03-23 10:43
說說我們網(wǎng)站現(xiàn)在數(shù)據(jù)庫部分的架構(gòu):
由于是基于JavaEE,我們使用的是jpa(jdbc) + mysql replication,
使用jdbc:mysql://mysqlmaster,mysqlslave 并設(shè)置failOverReadOnly=false的方式做HA,
由于JPA實現(xiàn)已經(jīng)包含了cache,將已讀數(shù)據(jù)作為二級緩存保存在WebServer上了,所以無需使用memcached
(通過java RMI等實現(xiàn)多WebServer間緩存同步)

作者: yuhongchun 時間: 2012-03-23 10:45
提示: 作者被禁止或刪除內(nèi)容自動屏蔽

作者: xjx922 時間: 2012-03-23 13:55

realmon 發(fā)表于 2012-03-23 10:43
說說我們網(wǎng)站現(xiàn)在數(shù)據(jù)庫部分的架構(gòu):
由于是基于JavaEE,我們使用的是jpa(jdbc) + mysql replication,
使用 ...

你們的日訪問量大概是多少呢？

作者: yuhongchun 時間: 2012-03-23 14:17
提示: 作者被禁止或刪除內(nèi)容自動屏蔽

作者: jagel 時間: 2012-03-23 18:41
還有獎品啊，不錯

作者: fire_cpp 時間: 2012-03-24 11:04
本帖最后由 fire_cpp 于 2012-03-24 11:15 編輯

一主多從是針對讀寫不平衡的情況的，如果寫入負載大于讀出，在不分表的情況下，有什么解決方案嗎？

作者: WaterDrops 時間: 2012-03-26 08:27
前來向大家學習支持支持

作者: 藍貓lanmao 時間: 2012-03-26 09:46
進來看看

作者: 藍貓lanmao 時間: 2012-03-26 09:48
進來看看

作者: ruochen 時間: 2012-03-26 10:01

Gray1982 發(fā)表于 2012-03-22 14:22
具備MC的cache功能的應(yīng)該很多吧
主要是看要cache多少東西，cache的內(nèi)容是什么，是不是允許丟失數(shù)據(jù)
...

我的意思是在具有MC的cache功能之外，具有游戲中需要的很多功能

作者: Gray1982 時間: 2012-03-26 10:19

ruochen 發(fā)表于 2012-03-26 10:01
我的意思是在具有MC的cache功能之外，具有游戲中需要的很多功能

這好像需要二次開發(fā)了吧··········

作者: huitoujian 時間: 2012-03-26 17:04
這獎品，我好喜歡！

有機大米品牌大米營養(yǎng)大米大米供應(yīng)商

作者: yuhongchun 時間: 2012-03-26 17:47
提示: 作者被禁止或刪除內(nèi)容自動屏蔽

作者: rootsecurity 時間: 2012-03-27 19:57
簡單扯幾句，我以前設(shè)計項目的架構(gòu)：

目標：某手機電影門戶站
數(shù)據(jù)庫：MySQL簡單的M/S模式
memcache最初用過一陣，后來換成redis，現(xiàn)在是2.4，采用的也是M/S模式 redis鴨梨明顯，特別是早上10點至下午2點這個時間段。

大家可以參考一下我的監(jiān)控：

a_01.jpg (90.26 KB, 下載次數(shù): 52)

a_02.jpg (102.75 KB, 下載次數(shù): 49)

作者: yuhongchun 時間: 2012-03-28 08:57
提示: 作者被禁止或刪除內(nèi)容自動屏蔽

作者: radkitty 時間: 2012-03-28 11:40
沙發(fā)中》。

作者: radkitty 時間: 2012-03-28 11:43
多數(shù)據(jù)庫結(jié)合，radis+mysql+oracle(sql server)

作者: hbsycw 時間: 2012-03-28 15:36

fire_cpp 發(fā)表于 2012-03-24 11:04
一主多從是針對讀寫不平衡的情況的，如果寫入負載大于讀出，在不分表的情況下，有什么解決方案嗎？

可以通過寫緩存來降低寫入負載~

作者: hbsycw 時間: 2012-03-28 15:48
我們目前的架構(gòu)是Master/Slaver，讀寫分離，一主多從

歡迎光臨 Chinaunix (http://72891.cn/)