偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

互聯(lián)網(wǎng)創(chuàng)業(yè)的準(zhǔn)備：硬盤IOPS與數(shù)據(jù)庫

作者：sink_cup
開發(fā) 項(xiàng)目管理
互聯(lián)網(wǎng)創(chuàng)業(yè)需要準(zhǔn)備什么？這篇文章給創(chuàng)業(yè)者講解了關(guān)于硬盤及數(shù)據(jù)庫的選擇，以及它們之間的關(guān)系……

硬盤常識：

  機(jī)械硬盤HDD 固態(tài)硬盤SSD
最小單位 1個(gè)扇區(qū)為512B，或4K（2012年民用普及） 1個(gè)分頁為4K、8K或更高（與密度有關(guān)）
性能因素 轉(zhuǎn)速（rpm）：5400、7200、1w、1.5w 層數(shù)：SLC（單層快）、MLC（雙層慢）、TLC（三層更慢，SSD暫未采用，U盤大量采用）
接口 SATA 3G、SATA 6G（2012年民用普及）、SAS 6G SATA 3G、SATA 6G、SAS 6G、PCI-E
尺寸 2.5英寸、3.5英寸 2.5英寸、PCI-E版型
常見品牌 西部數(shù)據(jù)、希捷 Intel、鎂光（Crucial）、浦科特（PLEXTOR）

硬盤性能指標(biāo)：

連續(xù)讀寫（常用單位為MB/s）：文件在硬盤上存儲(chǔ)位置是連續(xù)的，適用場景：大文件拷貝（比如視頻音樂）。速度即使很高，對數(shù)據(jù)庫性能也沒有參考價(jià)值。

4K隨機(jī)讀寫（常用單位為iops）：在硬盤上隨機(jī)位置讀寫數(shù)據(jù)，每次4KB，適用場景：操作系統(tǒng)運(yùn)行、軟件運(yùn)行、數(shù)據(jù)庫。（圖片靜態(tài)服務(wù)器、視頻靜態(tài)服務(wù)器是大文件，測試64K隨機(jī)或更大）

常用硬盤性能測試軟件：

Windows：AS SSD Benchmark、CrystalDiskMark、HD Tune Pro、iometer

Linux：iometer

Align I/Os：硬盤IO大小。測試設(shè)備時(shí)根據(jù)硬盤最小單位進(jìn)行選擇，機(jī)械硬盤上選512B或4K，SSD上選4K、8K等。測試分區(qū)時(shí)受分區(qū)sector size影響。由于Linux ext3的sector size為4096，所以在扇區(qū)為512B的機(jī)械硬盤上也無法選擇Align I/Os on 512B進(jìn)行測試，測試效果不佳。vps無法進(jìn)行設(shè)備測試，如果是自購服務(wù)器，應(yīng)使用設(shè)備測試。

Seq 即 Sequential 即連續(xù)讀寫。AS SSD會(huì)先以16MB的尺寸為單位，持續(xù)向受測分區(qū)寫入生成1個(gè)達(dá)到1GB大小的文件，然后再以同樣的單位尺寸讀取這個(gè)，最后計(jì)算平均成績而給出結(jié)果。

4K 即 Random 4k, Queue Depth=1 即 隨機(jī)4K并發(fā)1個(gè)隊(duì)列。AS SSD會(huì)以512KB的單位尺寸生成1GB大小的測試文件，然后在其地址范圍（LBA）內(nèi)進(jìn)行隨機(jī)4KB單位尺寸進(jìn)行寫入及讀取測試，直到跑遍這個(gè)范圍為止，最后同樣計(jì)算平均成績給出結(jié)果。

4K QD32 即 Random 4k, Queue Depth=32 即 隨機(jī)4K并發(fā)32個(gè)隊(duì)列。

4K-64Thrd 即 4K, 64 Thread 即 隨機(jī)4K并發(fā)64個(gè)線程，和 4K QD64是一個(gè)意思。AS SSD會(huì)生成64個(gè)16MB大小的測試文件（共計(jì)1GB），然后同時(shí)以4KB的單位尺寸，同時(shí)在這64個(gè)文件中進(jìn)行寫入和讀取測試，最后依然以平均成績?yōu)榻Y(jié)果。

通過AS SSD可以看出，iops與MB/s可以直接換算，比如4K讀取是6227iops，即每秒鐘可以讀取6227個(gè)4K的文件，即 6227 * 4K / 1024 = 24.3 MB/s。

Intel的SSD性能數(shù)據(jù)采用iometer 4K QD32的測試結(jié)果：http://www.intel.cn/content/www/cn/zh/solid-state-drives/solid-state-drives-520-series.html#footnotes

#p#

價(jià)格與速度：

  型號 容量 2012價(jià)格 4K QD32隨機(jī)讀/寫（iops） 4K QD64 連續(xù)讀寫（MB/s）
民用 機(jī)械7200rpm 3.5英寸 SATA 6G 希捷Barracuda 7200.14 3TB ￥1.1k 409/365 386/291 200/180
企業(yè)級 機(jī)械10000rpm 2.5英寸 SAS 6G  希捷Savvio 10K.5 300GB ￥1k 750/700   170/170
企業(yè)級 機(jī)械15000rpm 2.5英寸 SAS 6G 希捷Savvio 15K.3 300GB ￥2.2k      
企業(yè)級 固態(tài)SLC 2.5英寸 SATA 3G Intel X25-E 32G ￥2.5k 3.5w/3.3k   250/170
企業(yè)級 固態(tài)MLC PCI-E Intel 910 400G ￥14w 9w/3.8w   1000/750
企業(yè)級 固態(tài)MLC PCI-E Intel 710 100G ￥2.5k 3.8w/2.3k   270/170
民用 固態(tài)MLC 2.5英寸 SATA 6G Intel 520 120G ￥840 2.5w/8w   550/500
民用 固態(tài)MLC 2.5英寸 SATA 6G 鎂光 M4 128G ￥800 7.8w/4.2w 7w/4w 500/175

為什么民用SSD的iops很高價(jià)格卻很低，而企業(yè)級SSD的iops有的很低而價(jià)格卻很高？因?yàn)槠髽I(yè)級SSD的耐用性高，比如Intel 710 100G壽命為4K寫入500TB，即5000次全盤寫入。

Intel SSD壽命指標(biāo)：smart中的“E8：Avai lable Reserved Space”：可用的預(yù)留閃存數(shù)量、“E9：Media Wearout Indicator”：閃存磨耗指數(shù)。其他廠商的SSD類似，比如鎂光的wear leaving count。

SSD新盤的剩余磨損為100，當(dāng)?shù)陀?0時(shí)，應(yīng)更換，報(bào)廢。

todo：數(shù)據(jù)庫的選擇

關(guān)系型數(shù)據(jù)庫用Mysql還是PostgreSQL，或者全用NoSQL？mongo還是hbase？

Mysql 和 PostgreSQL都可以。mysql用的人多，但是oracle收購sun以后，把mysql限制的更加封閉，正在衰落，和可能和 OpenOffice一樣被oracle整死，衍生出LibreOffice。但不用很擔(dān)心，即使mysql被oracle整死，也會(huì)衍生出開源版本，使用方式一樣。

關(guān)系型數(shù)據(jù)庫和NoSQL搭配使用較好，關(guān)系型適合底層業(yè)務(wù)，NoSQL適合上層業(yè)務(wù)。關(guān)注淘寶hbase的使用。

Mysql性能與硬盤iops的關(guān)系：

mysql可以把讀取結(jié)果放在內(nèi)存中，即query cache，所以db server安裝大內(nèi)存即可實(shí)現(xiàn)只讀內(nèi)存、不讀硬盤。

當(dāng)預(yù)計(jì)數(shù)據(jù)量會(huì)增長到超過內(nèi)存大小時(shí)，進(jìn)行分表（把一個(gè)表中的數(shù)據(jù)拆分），放到多個(gè)大內(nèi)存服務(wù)器上，保證每個(gè)服務(wù)器上的數(shù)據(jù)都小于內(nèi)存大小，即可實(shí)現(xiàn)全部緩存。

2012年內(nèi)存價(jià)格：UDIMM no ECC DDR3 1600民用內(nèi)存 ￥270/8GB，RDIMM ECC DDR3 1600服務(wù)器內(nèi)存 ￥440/8G。但一臺(tái)服務(wù)器能安裝的內(nèi)存有限，2012年典型的Dell服務(wù)器有24個(gè)插槽，主板芯片支持768G內(nèi)存，2012年DDR3內(nèi)存生產(chǎn)工藝最高是單條 8G（DDR4已實(shí)現(xiàn)單條16G，但主板尚未支持DDR4），所以一臺(tái)服務(wù)器最大內(nèi)存192G（￥440 * 24條 = 1w）。

數(shù)據(jù)庫寫入時(shí)必須寫硬盤（否則就不叫持久化存儲(chǔ)了……），￥2.5k的Intel 710企業(yè)級SSD的寫入iops為2.3k，而萬轉(zhuǎn)硬盤的iops為700，如果要達(dá)到SSD的性能，需要多塊萬轉(zhuǎn)硬盤組RAID。如果使用iops為 3w的SSD，性能比機(jī)械硬盤提升了30倍。

如果數(shù)據(jù)量不大，遠(yuǎn)低于192G，就不需要做分表了嗎？

仍然要分表，原因有2個(gè)：

1、只讀內(nèi)存會(huì)提升mysql讀取性能，但并發(fā)讀取能力也是有上限的，這時(shí)受CPU性能限制，2012年典型的服務(wù)器是雙路，即2個(gè)8核CPU（mysql內(nèi)存并發(fā)待測試）。

2、內(nèi)存很大，對并發(fā)寫入能力沒有作用，寫入能力完全依賴于硬盤的iops。一臺(tái)服務(wù)器的寫入性能很有限，請看下面的測試。

為什么不進(jìn)行分庫（把不同的整個(gè)表放到不同的庫中，也就是不同的機(jī)器）？分庫簡單，但是一個(gè)表只增不減難于維護(hù)（比如評論表），大小總會(huì)超過內(nèi)存，又要改成分表；或者隨著用戶量增大，這個(gè)表的寫入量會(huì)逐漸增大，單臺(tái)機(jī)器必然無法承受，參考淘寶等網(wǎng)站的架構(gòu)演進(jìn)歷史就會(huì)發(fā)現(xiàn)這個(gè)問題。

為什么不用主從設(shè)計(jì)？因?yàn)槊總€(gè)“從”上面都有所有數(shù)據(jù)，數(shù)據(jù)量太大，同步壓力大，要做設(shè)計(jì)從每個(gè)“從”上面讀取不同的數(shù)據(jù)，以免內(nèi)存query cache不夠用，這增加了復(fù)雜度；即使“主”只進(jìn)行寫，寫入性能還有限，無法承受大并發(fā)。

所以最好在項(xiàng)目初期就使用分表設(shè)計(jì)，而不是分庫或主從設(shè)計(jì)，把分表設(shè)計(jì)做成一個(gè)成熟的方案（各個(gè)大型互聯(lián)網(wǎng)公司都已經(jīng)實(shí)現(xiàn)），各個(gè)項(xiàng)目通用，免得后期數(shù)據(jù)量大了拆分表，需要導(dǎo)數(shù)據(jù)，需要暫停線上服務(wù)。

mysql測試環(huán)境：

服務(wù)器：vr.org VR512、阿里云512、盛大云512

mysql版本：5.5.27

連接方式：unix domain socket

表：phpbb 3.0.7的users表，含有76個(gè)字段，28個(gè)char，43個(gè)int，1個(gè)主鍵，1個(gè)自增，1個(gè)unique，3個(gè)index。

  1. phpbb_users  
  2.  
  3. CREATE TABLE `phpbb_users` (  
  4.   `user_id` mediumint(8) unsigned NOT NULL AUTO_INCREMENT,  
  5.   `user_type` tinyint(2) NOT NULL DEFAULT '0',  
  6.   `group_id` mediumint(8) unsigned NOT NULL DEFAULT '3',  
  7.   `user_permissions` mediumtext COLLATE utf8_bin NOT NULL,  
  8.   `user_perm_from` mediumint(8) unsigned NOT NULL DEFAULT '0',  
  9.   `user_ip` varchar(40) COLLATE utf8_bin NOT NULL DEFAULT '',  
  10.   `user_regdate` int(11) unsigned NOT NULL DEFAULT '0',  
  11.   `username` varchar(255) COLLATE utf8_bin NOT NULL DEFAULT '',  
  12.   `username_clean` varchar(255) COLLATE utf8_bin NOT NULL DEFAULT '',  
  13.   `user_password` varchar(40) COLLATE utf8_bin NOT NULL DEFAULT '',  
  14.   `user_passchg` int(11) unsigned NOT NULL DEFAULT '0',  
  15.   `user_pass_convert` tinyint(1) unsigned NOT NULL DEFAULT '0',  
  16.   `user_email` varchar(100) COLLATE utf8_bin NOT NULL DEFAULT '',  
  17.   `user_email_hash` bigint(20) NOT NULL DEFAULT '0',  
  18.   `user_birthday` varchar(10) COLLATE utf8_bin NOT NULL DEFAULT '',  
  19.   `user_lastvisit` int(11) unsigned NOT NULL DEFAULT '0',  
  20.   `user_lastmark` int(11) unsigned NOT NULL DEFAULT '0',  
  21.   `user_lastpost_time` int(11) unsigned NOT NULL DEFAULT '0',  
  22.   `user_lastpage` varchar(200) COLLATE utf8_bin NOT NULL DEFAULT '',  
  23.   `user_last_confirm_key` varchar(10) COLLATE utf8_bin NOT NULL DEFAULT '',  
  24.   `user_last_search` int(11) unsigned NOT NULL DEFAULT '0',  
  25.   `user_warnings` tinyint(4) NOT NULL DEFAULT '0',  
  26.   `user_last_warning` int(11) unsigned NOT NULL DEFAULT '0',  
  27.   `user_login_attempts` tinyint(4) NOT NULL DEFAULT '0',  
  28.   `user_inactive_reason` tinyint(2) NOT NULL DEFAULT '0',  
  29.   `user_inactive_time` int(11) unsigned NOT NULL DEFAULT '0',  
  30.   `user_posts` mediumint(8) unsigned NOT NULL DEFAULT '0',  
  31.   `user_lang` varchar(30) COLLATE utf8_bin NOT NULL DEFAULT '',  
  32.   `user_timezone` decimal(5,2) NOT NULL DEFAULT '0.00',  
  33.   `user_dst` tinyint(1) unsigned NOT NULL DEFAULT '0',  
  34.   `user_dateformat` varchar(30) COLLATE utf8_bin NOT NULL DEFAULT 'd M Y H:i',  
  35.   `user_style` mediumint(8) unsigned NOT NULL DEFAULT '0',  
  36.   `user_rank` mediumint(8) unsigned NOT NULL DEFAULT '0',  
  37.   `user_colour` varchar(6) COLLATE utf8_bin NOT NULL DEFAULT '',  
  38.   `user_new_privmsg` int(4) NOT NULL DEFAULT '0',  
  39.   `user_unread_privmsg` int(4) NOT NULL DEFAULT '0',  
  40.   `user_last_privmsg` int(11) unsigned NOT NULL DEFAULT '0',  
  41.   `user_message_rules` tinyint(1) unsigned NOT NULL DEFAULT '0',  
  42.   `user_full_folder` int(11) NOT NULL DEFAULT '-3',  
  43.   `user_emailtime` int(11) unsigned NOT NULL DEFAULT '0',  
  44.   `user_topic_show_days` smallint(4) unsigned NOT NULL DEFAULT '0',  
  45.   `user_topic_sortby_type` varchar(1) COLLATE utf8_bin NOT NULL DEFAULT 't',  
  46.   `user_topic_sortby_dir` varchar(1) COLLATE utf8_bin NOT NULL DEFAULT 'd',  
  47.   `user_post_show_days` smallint(4) unsigned NOT NULL DEFAULT '0',  
  48.   `user_post_sortby_type` varchar(1) COLLATE utf8_bin NOT NULL DEFAULT 't',  
  49.   `user_post_sortby_dir` varchar(1) COLLATE utf8_bin NOT NULL DEFAULT 'a',  
  50.   `user_notify` tinyint(1) unsigned NOT NULL DEFAULT '0',  
  51.   `user_notify_pm` tinyint(1) unsigned NOT NULL DEFAULT '1',  
  52.   `user_notify_type` tinyint(4) NOT NULL DEFAULT '0',  
  53.   `user_allow_pm` tinyint(1) unsigned NOT NULL DEFAULT '1',  
  54.   `user_allow_viewonline` tinyint(1) unsigned NOT NULL DEFAULT '1',  
  55.   `user_allow_viewemail` tinyint(1) unsigned NOT NULL DEFAULT '1',  
  56.   `user_allow_massemail` tinyint(1) unsigned NOT NULL DEFAULT '1',  
  57.   `user_options` int(11) unsigned NOT NULL DEFAULT '230271',  
  58.   `user_avatar` varchar(255) COLLATE utf8_bin NOT NULL DEFAULT '',  
  59.   `user_avatar_type` tinyint(2) NOT NULL DEFAULT '0',  
  60.   `user_avatar_width` smallint(4) unsigned NOT NULL DEFAULT '0',  
  61.   `user_avatar_height` smallint(4) unsigned NOT NULL DEFAULT '0',  
  62.   `user_sig` mediumtext COLLATE utf8_bin NOT NULL,  
  63.   `user_sig_bbcode_uid` varchar(8) COLLATE utf8_bin NOT NULL DEFAULT '',  
  64.   `user_sig_bbcode_bitfield` varchar(255) COLLATE utf8_bin NOT NULL DEFAULT '',  
  65.   `user_from` varchar(100) COLLATE utf8_bin NOT NULL DEFAULT '',  
  66.   `user_icq` varchar(15) COLLATE utf8_bin NOT NULL DEFAULT '',  
  67.   `user_aim` varchar(255) COLLATE utf8_bin NOT NULL DEFAULT '',  
  68.   `user_yim` varchar(255) COLLATE utf8_bin NOT NULL DEFAULT '',  
  69.   `user_msnm` varchar(255) COLLATE utf8_bin NOT NULL DEFAULT '',  
  70.   `user_jabber` varchar(255) COLLATE utf8_bin NOT NULL DEFAULT '',  
  71.   `user_website` varchar(200) COLLATE utf8_bin NOT NULL DEFAULT '',  
  72.   `user_occ` text COLLATE utf8_bin NOT NULL,  
  73.   `user_interests` text COLLATE utf8_bin NOT NULL,  
  74.   `user_actkey` varchar(32) COLLATE utf8_bin NOT NULL DEFAULT '',  
  75.   `user_newpasswd` varchar(40) COLLATE utf8_bin NOT NULL DEFAULT '',  
  76.   `user_form_salt` varchar(32) COLLATE utf8_bin NOT NULL DEFAULT '',  
  77.   `user_new` tinyint(1) unsigned NOT NULL DEFAULT '1',  
  78.   `user_reminded` tinyint(4) NOT NULL DEFAULT '0',  
  79.   `user_reminded_time` int(11) unsigned NOT NULL DEFAULT '0',  
  80.   PRIMARY KEY (`user_id`),  
  81.   UNIQUE KEY `username_clean` (`username_clean`),  
  82.   KEY `user_birthday` (`user_birthday`),  
  83.   KEY `user_email_hash` (`user_email_hash`),  
  84.   KEY `user_type` (`user_type`)  
  85. ) ENGINE=InnoDB AUTO_INCREMENT=53 DEFAULT CHARSET=utf8 COLLATE=utf8_bin 

mysql配置：

并發(fā)默認(rèn)151，超過時(shí)會(huì)出現(xiàn)“1040 Too many connections”，修改為99999：set global max_connections=99999;

超過1024時(shí)，碰到了Linux “open files”限制，出現(xiàn)錯(cuò)誤“2001 Can't create UNIX socket (24)”。修改為99999：ulimit -n 99999

#p#

測試程序：

write 和 update 直接寫入硬盤，這時(shí)要注意iowait。

key 和 read 每次先寫入99條數(shù)據(jù)（這時(shí)影響觀測iowait），然后并發(fā)查詢，然后刪除數(shù)據(jù)，重新生成。比如iterations=10，就會(huì)生成10次。如果并發(fā) 1000，那很快就會(huì)把所有數(shù)據(jù)query cache起來，速度變快。這種情況和生產(chǎn)環(huán)境類似，保證內(nèi)存大于數(shù)據(jù)庫，數(shù)據(jù)只讀一次硬盤，以后一直在內(nèi)存中，所以不觀測iowait。

  1. ./mysqlslap --auto-generate-sql --number-char-cols=28 --number-int-cols=43 --auto-generate-sql-load-type=write --auto-generate-sql-add-autoincrement --socket=/tmp/mysql.sock --concurrency=800 --number-of-queries=800 --user=root --password=1 --iterations=10 

如果不考慮讀一次硬盤，內(nèi)存中cache了所有數(shù)據(jù)，是不是read并發(fā)就會(huì)很大？經(jīng)測試，稍微大了一點(diǎn)，這時(shí)iowait顯然為0，但CPU 100%，如果CPU更強(qiáng)，并發(fā)預(yù)計(jì)會(huì)進(jìn)一步提高。

先寫入1w條，只查某一條，確保query cache，mysqlslap key時(shí)并發(fā)為1300，全內(nèi)存時(shí)為1700。

  1. ./mysqlslap --query='select * from t1 limit 1;' --socket=/tmp/mysql.sock --concurrency=800 --number-of-queries=800 --user=root --password=1 --iterations=10 

mysql性能判斷規(guī)則：

Average number of seconds to run all queries < 1秒，比如800個(gè)并發(fā)，執(zhí)行800個(gè)sql，如果在1秒內(nèi)不能完成，就會(huì)影響下一秒的800并發(fā)。

iops測試環(huán)境：

分區(qū)測試 還是 設(shè)備測試：分區(qū)測試。

  4K QD32隨機(jī)讀/寫（iops） 硬盤到內(nèi)存mysql key（按主鍵讀） 硬盤到內(nèi)存mysql read
 硬盤mysql write
 硬盤mysql update 硬盤mysql mixed
vr.org VR512 100-300/700-2900波動(dòng)很大 并發(fā)1300，0.98s 并發(fā)180，0.91s 并發(fā)800，0.98s，iowait < 21 并發(fā)800，0.92s，iowait < 15 并發(fā)900，0.97s，iowait < 16
阿里云主機(jī)            
阿里云數(shù)據(jù)庫            
盛大云主機(jī) 512 Windows 300-420/350-400波動(dòng)不大    

 

    
盛大云主機(jī) 512 Linux 70-90/550波動(dòng)不大 并發(fā)1300，0.97s
 并發(fā)300，0.99s 并發(fā)1300，0.97s，iowait < 21 并發(fā)1100，0.96s，iowait < 18  并發(fā)1200，0.91s，iowait < 25
盛大云數(shù)據(jù)庫            

mysql測試圖：

傳統(tǒng)web服務(wù)的mysql壓力：

讀取量大，寫入量小，所以加大內(nèi)存即可。

案例：

1、小米論壇（bbs.xiaomi.cn），在2012年9月10日發(fā)帖和回帖合計(jì)89w，PV約2000w。

每次發(fā)帖回帖需要發(fā)表（同步）、增加積分（異步）等操作，按每次發(fā)帖需要3次同步寫數(shù)據(jù)庫算，89w * 3次 / （15h * 3600s）* 高峰時(shí)2倍 = 99次寫/s。

頁面數(shù)據(jù)在業(yè)務(wù)層、頁面層有緩存，實(shí)際讀取數(shù)據(jù)庫按每次瀏覽需要1次讀數(shù)據(jù)庫算，2000w / （15h * 3600s）* 高峰時(shí)2倍 = 740次讀/s。

按一臺(tái)微型vps db并發(fā)900計(jì)算，兩臺(tái)vps db即可承受，一臺(tái)自購服務(wù)器Raid即可承受。

2、遠(yuǎn)景論壇（bbs.pcbeta.com），在2012年8月Windows 8發(fā)布后，每天發(fā)帖回帖1.9w。

數(shù)據(jù)庫寫入并發(fā)：1.9w * 3次 / （15h * 3600s）* 高峰時(shí)2倍 = 2次寫/s。

3、instagram使用Amazon云服務(wù)，達(dá)到820w UV，那也是普通web服務(wù)，并發(fā)很低，假設(shè)是5000w PV，并發(fā)量才 5000w / (15小時(shí) * 3600)  = 900。

“秒殺”服務(wù)的mysql壓力：

像小米手機(jī)搶購、淘寶光棍節(jié)促銷，這種“秒殺”服務(wù)流量集中在瞬間，而不是全天，并發(fā)寫入量大、并發(fā)讀取量更大。

#p#

案例：

2012年8月23日10點(diǎn)，小米1S開放購買20w臺(tái)，事先有個(gè)預(yù)定量統(tǒng)計(jì)，約160w人，到了秒殺時(shí)間并發(fā)量讀取為每秒十萬級（登錄、刷新），登錄頁面正常顯示，但提交后返回500錯(cuò)誤，數(shù)據(jù)庫讀取壓力達(dá)到極限，登錄很困難……

[[94238]]

假設(shè)有50w人10點(diǎn)準(zhǔn)時(shí)搶購，有30w人卡在登錄步驟，一直刷新提交，按讀取并發(fā)10w計(jì)算，微型vps的每臺(tái)mysql為1300，需要76臺(tái)微型vps……顯然不合理，成本太高。購買云數(shù)據(jù)庫也無法保證10w并發(fā)（云數(shù)據(jù)庫待測試）。

按機(jī)械硬盤Raid的自購服務(wù)器mysql key為3000計(jì)算（參考值，待有條件時(shí)測試），需要33臺(tái)服務(wù)器……

假如使用Intel 710 SSD，讀取iops為3.8w，預(yù)計(jì)mysql key為5w，只需要2塊SSD即可。

29分36秒搶購結(jié)束，數(shù)據(jù)庫寫入為 20w / 1776秒 = 112次/s，由于卡在了登錄，所以寫入量不大。

2012年9月6日10點(diǎn)，小米1S開放購買5w臺(tái)電信版+15w臺(tái)標(biāo)準(zhǔn)版，預(yù)定量未公布。參考上次160w的預(yù)定量，假設(shè)這次一樣人數(shù)。

由于數(shù)據(jù)庫讀寫能力有限，采用了分批選取一部分用戶可以看見“驗(yàn)證預(yù)約信息”的鏈接，別的用戶都看見“您沒有購買小米手機(jī)1s的特權(quán)”，這一批處理完了，再選取下一批。

這句話語義錯(cuò)誤，因?yàn)檫@些用戶都是已經(jīng)預(yù)約的，導(dǎo)致用戶投訴。

9分40秒搶購結(jié)束。

20w訂單，數(shù)據(jù)庫寫入為 20w / 580秒 = 344次/s

第一次搶購卡在登錄，第二次搶購分批影響用戶體驗(yàn)。

如果不分批，進(jìn)行正常搶購，160w中有50w人在10點(diǎn)等待著，ajax檢查登錄返回?fù)屬忔溄樱ㄈ绻褂胢emcache session或者mongo session，要考慮nosql并發(fā)。如果使用無需存儲(chǔ)的加密仿session，需要考慮cpu能承受多少并發(fā)計(jì)算加密對比），

花費(fèi)5秒輸入預(yù)約信息（復(fù)制粘貼4秒，如果手打8秒），

然后提交數(shù)據(jù)庫進(jìn)行驗(yàn)證，數(shù)據(jù)庫要承受10w-20w/s的讀取壓力，

都是預(yù)約過的，50w都人驗(yàn)證通過，點(diǎn)擊購買下訂單，數(shù)據(jù)庫要承受10w-20w/s的寫入壓力。

所以，如果創(chuàng)業(yè)公司業(yè)務(wù)要做秒殺，需要自購服務(wù)器（用SSD Raid，加大內(nèi)存），而不是采用云服務(wù)。

如果購買品牌服務(wù)器，可以自行購買SSD和內(nèi)存，因?yàn)榉?wù)器廠商提供的配件要貴2倍以上。

比如dell 8核 1U、2U服務(wù)器價(jià)格約￥1.4w，但選配的硬盤很貴，參考文章末尾的截圖。

所以無論是PC還是server，DIY一直是高性能低價(jià)格的終極解決方案。

如果ODM自行設(shè)計(jì)服務(wù)器，參考Facebook開放服務(wù)器計(jì)劃：http://news.cnblogs.com/n/133536/

Dell服務(wù)器硬件價(jià)格圖：

#p#

硬盤iops測試圖：

參考資料：

http://tech.sina.com.cn/h/2012-08-02/09337458765_2.shtml

http://forum.crucial.com/t5/Solid-State-Drives-SSD/Page-size-and-erase-block-size-for-M4-64GB-128GB-256GB-models/m-p/64461#M19888

http://article.pchome.net/content-1515362-7.html

http://bbs.xiaomi.cn/forum.php?mod=viewthread&tid=4615631

http://news.cnblogs.com/n/133536/

http://www.liusuping.com/it-tech/server-rdimm-udimm.html

http://ssd.zol.com.cn/252/2529054.html

http://ssd.zol.com.cn/303/3031977.html

http://www.ssdfreaks.com/content/599/how-to-convert-mbps-to-iops-or-calculate-iops-from-mbs

http://www.xfastest.com/thread-65671-1-1.html

http://bbs.pceva.com.cn/thread-36832-1-1.html

http://tech.watchstor.com/storage-module-136610.htm

http://isjin.blog.51cto.com/612537/528622

http://www.datacentersky.com/undeer-linux-use-iometer.html

http://www.datacentersky.com/taught-you-how-to-use-iometer-test-tool-to-test-storage.html

http://cnbeta.com/articles/202141.htm

原文鏈接：http://www.cnblogs.com/sink_cup/archive/2012/09/17/ssd_iops_sql_nosql.html

責(zé)任編輯：林師授 來源： 博客園
互聯(lián)網(wǎng)創(chuàng)業(yè)項(xiàng)目
相關(guān)推薦

2012-09-18 13:55:02

互聯(lián)網(wǎng)創(chuàng)業(yè)數(shù)據(jù)備份

2012-09-18 13:58:58

互聯(lián)網(wǎng)創(chuàng)業(yè)架構(gòu)

2012-09-18 13:34:27

互聯(lián)網(wǎng)創(chuàng)業(yè)帶寬

2012-09-19 15:23:06

2012-09-18 13:41:09

2012-09-18 13:24:10

互聯(lián)網(wǎng)創(chuàng)業(yè)項(xiàng)目

2012-09-18 13:47:54

互聯(lián)網(wǎng)創(chuàng)業(yè)云主機(jī)

2015-05-28 16:11:07

互聯(lián)網(wǎng)+

2012-09-27 13:49:54

2018-08-15 09:02:59

產(chǎn)業(yè)互聯(lián)網(wǎng)工業(yè)互聯(lián)網(wǎng)物聯(lián)網(wǎng)

2013-06-24 09:39:34

移動(dòng)互聯(lián)網(wǎng)創(chuàng)業(yè)投資

2018-05-16 14:24:53

2022-12-27 09:31:01

2012-12-31 09:50:12

互聯(lián)網(wǎng)創(chuàng)業(yè)創(chuàng)業(yè)者創(chuàng)業(yè)

2017-08-03 16:37:35

互聯(lián)網(wǎng)法院司法

2013-06-24 13:52:31

創(chuàng)業(yè)互聯(lián)網(wǎng)創(chuàng)業(yè)

2013-09-12 14:20:06

騰訊云騰訊

2012-09-28 03:19:27

互聯(lián)網(wǎng)創(chuàng)業(yè)調(diào)研報(bào)告

2013-09-11 11:46:06

騰訊云互聯(lián)網(wǎng)創(chuàng)業(yè)

2015-10-30 14:24:44

互聯(lián)網(wǎng)+中醫(yī)創(chuàng)業(yè)
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號