網站簡訊發送介面一直在被人循環調用, 嚴重影響到app 端的運行性能, 我是先把網站關掉了, 但是接口一直還在調用, 性能問題還是沒解決, 求問解決思路環境: windows server 2008 + apache + php + mysql
有幾個解決思路，我分別簡單介紹下。 第一種，可以查看access.log日誌，看一下接口訪問情況，某個IP如果一分鐘內幾十次那肯定是在刷了，可以對這個IP做一些限速或者封禁處理，比如這個IP再訪問你可以按照自訂的規則讓他去按一定時間訪問，或者乾脆直接黑名單，網絡層直接拒絕一切訪問。 第二種思路，記錄下訪問IP，和每分鐘最大訪問次數和訪問時間，當用戶訪問接口並提交成功後，相關信息放到Memcache或者Redis裡，做一個對比如果過期了再提交，沒過期就不提交。 第三種思路，做反向代理，內部才能呼叫接口，然後在代理層對訪問進行限制，其實跟第一種思路差不太多。
以上是我個人思考的，不一定是最優的解決方案，歡迎大家批評指正。
發送簡訊前需先驗證圖形驗證碼，圖形驗證碼也要在後端驗證
簡訊介面一定要做限制的。驗證碼限制 ip限制 手機號碼限制。要不然一天幾萬塊都能刷出去
1.服務端控制每個手機號碼 每天發送的次數,例如每天只能發3次
2.服務端每次發送簡訊,必須填寫驗證碼
mark下 網站簡訊介面被爬, 影響到網站效能
有幾個解決思路，我分別簡單介紹下。
第一種，可以查看access.log日誌，看一下接口訪問情況，某個IP如果一分鐘內幾十次那肯定是在刷了，可以對這個IP做一些限速或者封禁處理，比如這個IP再訪問你可以按照自訂的規則讓他去按一定時間訪問，或者乾脆直接黑名單，網絡層直接拒絕一切訪問。
第二種思路，記錄下訪問IP，和每分鐘最大訪問次數和訪問時間，當用戶訪問接口並提交成功後，相關信息放到Memcache或者Redis裡，做一個對比如果過期了再提交，沒過期就不提交。
第三種思路，做反向代理，內部才能呼叫接口，然後在代理層對訪問進行限制，其實跟第一種思路差不太多。
以上是我個人思考的，不一定是最優的解決方案，歡迎大家批評指正。
發送簡訊前需先驗證圖形驗證碼，圖形驗證碼也要在後端驗證
簡訊介面一定要做限制的。驗證碼限制 ip限制 手機號碼限制。要不然一天幾萬塊都能刷出去
1.服務端控制每個手機號碼 每天發送的次數,例如每天只能發3次
2.服務端每次發送簡訊,必須填寫驗證碼
mark下 網站簡訊介面被爬, 影響到網站效能