中華電信iphone5預購系統,雖然不是我實作的,但預購的同時,被我猜到了幾點:
1. 閘道管制: 前端使用類似CSM的MaxConnection控管機制。
2. 不同手機有不同的伺服器:所以我點冷門,速度會較快。
對付閘道管制,開很多電腦、手機或開很多瀏覽器(IE,IE Private,Chrome,Chrome無痕,Firefox,Opera),無痕視窗算另外的連線喔!開了十倍的連覽器,連進去的機率就是別的人的十倍。
這個CASE如何創新?
系統設計上還是看出前端再怎麼強化,或提高快取擊中率,瓶頸最後還是卡在資料庫上。
那就暫時不要用資料庫,將手機號碼、登錄時間、型號、直接在應用伺服器利用雙向金鑰(RSA、DES)加密起來,把密文送給用戶,用戶在N天內回再把密文送給解密伺服器,慢慢回填給資料庫伺服器即可。
這樣可以有效舒緩資料庫伺服器的瓶頸、只要調用雲端主機增加應用伺服器的數量即可。
這方法聽來也可行,乍看主要缺點會在overbooking太大量,也許可以搭配單一門號限定預約支數以及領貨時的一些驗證手續,就可以有效降低黃牛操作空間?另一個缺點應在二次操作的不便,如何說服用戶應是另一挑戰。
1. 閘道管制: 前端使用類似CSM的MaxConnection控管機制。
2. 不同手機有不同的伺服器:所以我點冷門,速度會較快。
對付閘道管制,開很多電腦、手機或開很多瀏覽器(IE,IE Private,Chrome,Chrome無痕,Firefox,Opera),無痕視窗算另外的連線喔!開了十倍的連覽器,連進去的機率就是別的人的十倍。
這個CASE如何創新?
系統設計上還是看出前端再怎麼強化,或提高快取擊中率,瓶頸最後還是卡在資料庫上。
那就暫時不要用資料庫,將手機號碼、登錄時間、型號、直接在應用伺服器利用雙向金鑰(RSA、DES)加密起來,把密文送給用戶,用戶在N天內回再把密文送給解密伺服器,慢慢回填給資料庫伺服器即可。
這樣可以有效舒緩資料庫伺服器的瓶頸、只要調用雲端主機增加應用伺服器的數量即可。
這方法聽來也可行,乍看主要缺點會在overbooking太大量,也許可以搭配單一門號限定預約支數以及領貨時的一些驗證手續,就可以有效降低黃牛操作空間?另一個缺點應在二次操作的不便,如何說服用戶應是另一挑戰。