遇到的问题:
解决方案的个人想法:
重构,借用工具。上线必须保证:httpunit功能测试,LoadRunner负载测试通过。
利用大数据分析,将业务问题转化为大数据问题。日志分析,监控异常,逻辑优化,响应时长分析,并发分析,数据恢复,保存现场数据,提供可持续改进的数据基础。
提供数据的频率:
反正我的blog除了乐视同事也没有别人看,不涉及信息安全。把接口架构图放在这里,以后好找:
不是我画的图果然就看起来高端大气上档次[汗]。性能优化是我的日常工作,可以慢慢来。如果遇到什么闹心的线上事故,建议看看
《打错一个字母-瘫痪半个互联网 亚马逊AWS的云存储服务S3超高错误率宕机事件》
《google.com宕机一小时》
《gitlab程序猿用一条错误命令误删了整个数据库》
心情会好很多!
今天开会确定的方案,这里备忘一下:
1 从上面架构图中可以看出安外联通的cbase只是做了一个冷备,会面临网络抖动的问题;马驹桥电信一旦故障,需要手动切换。冷备的机器虽然是正常写入的,但是数据没有经过检验,切换后的数据一致性隐患问题;跨机房的性能问题。所以我们决定改成联通和电信做一个物理隔离。这样做需要解决的问题:swiftq给联通和电信发消息,两端接受和处理消息的时机不一样,但是只有两段都更新成功后才能给各端发通知消息的更新,涉及到策略的问题。一旦一边更新失败,需要有补偿机制,补偿的策略问题。部署的复杂性提高,合理部署的问题。
2 memcache的mget在数据量大时性能急剧下降的问题。性能急剧下降时占用连接导致阻塞的问题。测试时需要注意key的数量以及value大小的双重变化影响。
3 cbase读写分离的问题
另外,我们是基础服务部门,应该可以不使用http协议来调用