@
inza9hi #45
按照你说的,我就假设你是做广告联盟类的业务,大写入记录,流出基本就是一些死的参数,其实这个很匹配我这边现在的一个系统,就是纯向上写入型的
我这有一个 mysql 单表日写入记录 1.3 亿行的,写居多读极少,报表为主的业务,到一定日子就狂删数据 后端 MYSQL INNODB CLUSTER 汇总库 存储规模已经接近 10TB 级数据 这也是我这边最早吃 innodb cluster 螃蟹的一个应用
也是用户侧延迟敏感的,甚至都不是 https 的前端,都是 websocket 的前端,为了快速把用户侧的采集数据反馈回来,是长连接反馈数据的
程序架构直接分布了,业务跑在边缘,后置汇总数据
这种用云厂商负载均衡器本身就没啥卵用 我这给出的结构都是直接分布式多级数据,后置汇总
这样才能保证偏远地区的末端延迟,单纯的你放在一个 BGP 的全国中心点都不可接受
就这种系统,我这单月云带宽成本都不到 2 万,各种钻云厂商计费模式的空子
而且还有各种云下单线数据中心处理区域请求
这个架构不是单纯的云架构,要站在一个高处,能去指挥整个业务程序的架构铺设,进行规划,可用性,用户侧延迟,都做到极限,否则没啥用