高並發寫入mysql的設計

最近開發一個專案。客戶端每隔10秒提交100行資料給服務端，服務端查重後寫入。
客戶端約在數萬左右，提交資料比較集中，不考慮讀取資料的問題。
現在的設計是：
資料庫會依照客戶端進行分錶。每個表的資料量不高。
服務端取得資料後，先插入redis佇列，然後在透過定時任務插入資料庫。
問題是：
1、服務端提供給客戶端的接口，是否能滿足幾千上萬的客戶端同時post資料(客戶端是10秒提交一次)？
2、將數據先保存在redis隊列中，如果有幾十上百萬的數據，redis是否穩定？
基本目標是確保服務端能正常提供服務。

---------------------- 補充內容------------------------ ------
專案主要是採集使用者的資料。開機就會自動運轉。
每次提交100條，10秒提交一次，一般用戶每天在10次以內，也就是1000條數據以內。
每條資料包含五到六個值對，在100字元以內。
需要保證每天資料的完整性。會出現多個客戶端採集相同用戶資料的情況，所以需要避免重複。

現在考慮是這樣的：
資料表按使用者分錶。
使用者提交的資料依使用者先保存在redis佇列中，也就是每個使用者每天一個佇列，儲存到資料庫後，刪除該佇列。

回覆內容：

最近開發一個專案。客戶端每隔10秒提交100行資料給服務端，服務端查重後寫入。
客戶端約在數萬左右，提交資料比較集中，不考慮讀取資料的問題。
現在的設計是：
資料庫會依照客戶端進行分錶。每個表的資料量不高。
服務端取得資料後，先插入redis佇列，然後在透過定時任務插入資料庫。
問題是：
1、服務端提供給客戶端的接口，是否能滿足幾千上萬的客戶端同時post資料(客戶端是10秒提交一次)？
2、將數據先保存在redis隊列中，如果有幾十上百萬的數據，redis是否穩定？
基本目標是確保服務端能正常提供服務。

---------------------- 補充內容------------------------ ------
專案主要是採集使用者的資料。開機就會自動運轉。
每次提交100條，10秒提交一次，一般用戶每天在10次以內，也就是1000條數據以內。
每條資料包含五到六個值對，在100字元以內。
需要保證每天資料的完整性。會出現多個客戶端採集相同用戶資料的情況，所以需要避免重複。

現在考慮是這樣的：
資料表按使用者分錶。
使用者提交的資料依使用者先保存在redis佇列中，也就是每個使用者每天一個佇列，儲存到資料庫後，刪除該佇列。

1. 合併插入，不要1條1條插入，例如對應同一張的插入操作，合併1000條插入，這樣可以減少交互的次數

2. 如果這張表只是簡單的插入和查詢的操作，不需要事務支援的，可以考慮使用MyISAM引擎，相對於InnoDB，在插入時可以獲得更高的效能

第一個，有幾個考慮

1. 頻寬是否足夠

2. cpu數量，假如4核，php-fpm的數量也是4個的話，每個請求需要50-150ms的處理時間，算下持續時間內處理的請求量大概是多少。

3. 內存，一個進程10-25M的內存佔用。

可以考慮的有：負載平衡，dns輪詢。同時注意集群的高可用性。

第二個，也有幾個考慮

1. 資料行，一行的長度是？ redis對於1k以上都會有效能下降。

2. 處理速度，隊列裡面會堆積多少數據，佔用記憶體多大

3. redis架構，如何確保資料不遺失，如何做高可用

4. 目前的資源是否允許該方案，是否有其它方案。

並發寫不行？那就主主雙活，並發寫減壓50%

使用MyCat

可以做資料庫sharding，一致性hash或簡單的id進行區間hash，應該可以滿足吧，如果感覺麻煩，讀寫分離先看看負載

用隊列試試？

看題主說資料產生相對集中...那麼可以考慮下利用佇列任務將集中的任務時段稍微拉寬一點....盡量平滑寫入...需要在寫入讀取延遲和平滑處理時長之間找一個合理的平衡點即可....要是實在是沒得讓步餘地就其實前面說的高端路子...另外不想折騰數據庫的話也可以試試先寫到dump文件...另一個配套導入....不知道這算不算野路子....

-1. 一次提交100條，10秒來處理顯然是比較急的，我假定你的數據是允許部分丟失的前提下，可以考慮在客戶端做緩存(把數據緩存在客戶端,其實是一種冒險的做法)，例如我200條，20秒提交一次。
-2. 服務端可以採用任務佇列，減少伺服器的阻塞，進而提高並發。 （10秒提交一次，很容易出現高併發）

-3. 另外要考慮資料是否經常進行讀寫,否則建議才有ehcache,叢集同步帶來額外的開支。

-4. 這麼特殊的業務肯定不要跟其他業務公用伺服器了.

-5. 後面關於怎麼分錶的,這個得看你的業務了.