PHP多進程與MySQL的高併發瓶頸處理

最近開發一個項目。客戶端每隔10秒提交100行數據給服務端，服務端查重後寫入。
客戶端約在幾萬左右，提交數據比較集中，不考慮讀數據的問題。
如今的設計是：
數據庫按客戶端進行分表。每一個表的數據量不高。
服務端得到數據後，先插入redis隊列，而後在經過定時任務插入數據庫。
問題是：
一、服務端提供給客戶端的接口，是否能知足幾千上萬的客戶端同時post數據(客戶端是10秒提交一次)？
二、將數據首先保存在redis隊列中，若是有幾十上百萬的數據，redis是否穩定？
基本目標是保證服務端能正常提供服務。

---------------------- 補充內容 -------------------------------
項目主要是採集用戶的數據。開機就會自動運行。
每次提交100條，10秒提交一次，通常用戶天天在10次之內，也就是1000條數據之內。
每條數據包含五六個值對，在100字符之內。
須要保證天天數據的完整性。會出現多個客戶端採集同一用戶數據的狀況，因此須要避免重複。

如今考慮是這樣的：
數據表按用戶分表。
用戶提交的數據按用戶先保存在redis隊列中，即每一個用戶天天一個隊列，保存到數據庫後，刪除該隊列。

 

 

 

=====================================================================

寫過相似的東西,像這種須要屢次更新同一帳號數據的時候,咱們的作法是處理完數據後不當即存入mysql,
而是放在了redis中,後面的數據更新都在redis修改,
在redis積累了數千條數據後在異步的寫一次數據到mysql,效果不錯
滷煮的場景多進程處理建議只負責數據處理,處理完的放redis,在單獨用一個腳本定時檢測redis
達到條件的時候(必定條數或時間)存一次數據到mysql

=====================================================================

1，讀加緩存。
2，寫加隊列。
3，推薦Redis。
4，分庫分表分機器。