最近開發乙個專案。客戶端每隔10秒提交100行資料給服務端，服務端查重後寫入。
客戶端約在幾萬左右，提交資料比較集中，不考慮讀資料的問題。
現在的設計是：
資料庫按客戶端進行分表。每個表的資料量不高。
服務端獲得資料後，先插入redis佇列，然後在通過定時任務插入資料庫。
問題是：
1、服務端提供給客戶端的介面，是否能滿足幾千上萬的客戶端同時post資料(客戶端是10秒提交一次)？
2、將資料首先儲存在redis佇列中，如果有幾十上百萬的資料，redis是否穩定？
基本目標是保證服務端能正常提供服務。
---------------------- 補充內容 -------------------------------
專案主要是採集使用者的資料。開機就會自動執行。
每次提交100條，10秒提交一次，一般使用者每天在10次以內，也就是1000條資料以內。
每條資料報含五六個值對，在100字元以內。
需要保證每天資料的完整性。會出現多個客戶端採集同一使用者資料的情況，所以需要避免重複。
現在考慮是這樣的：
資料表按使用者分表。
使用者提交的資料按使用者先儲存在redis佇列中，即每個使用者每天乙個佇列，儲存到資料庫後，刪除該佇列。
解決辦法：
高併發架構
1 高併發中一些概念 1.pv 訪問量 頁面訪問量，頁面重新整理一次算一次。2.uv 獨立訪客 即unique visitor，乙個客戶端 電腦，手機 為乙個訪客 3.dau 日活躍使用者數 登入或使用了某個產品的使用者數，這與流量統計工具裡的訪客 uv 概念相似。4.峰值qps 原理 每天80 的...
nginx伺服器高併發配置詳解 單機3w 併發
系統配置 壓測測試部分問題 以前沒有動手實踐高併發系統搭建，對它的認知侷限在事務控制，非同步處理，微服務，負載均衡的應用層處理上。這兩天在伺服器的實踐調優，了解如何配置引數，更重要的是知道為什麼要這麼配置，從而認識到了應用與作業系統的一些相關聯絡。這個過程遇到了許多bug和系統相關，在這次記錄中也會...
高併發高負載系統架構
一 為什麼要進行高併發和高負載的研究 1 產品發展的需要 2 公司發展的需要 3 當前形式決定的 二 高併發和高負載的約束條件 1 硬體 2 部署 3 作業系統 4 web 伺服器 5 php 6 mysql 7 測試 三 解決之道 硬體篇 處理能力的提公升 部署多顆cpu，選擇多核心 具備更高運算...