突然发现，今天是情人节。
窗外卖花的姑娘还在，但我得守着机房那一堆服务器的监控数据。
干运维的，数据库要是挂了，比失恋还难受。
特别是时序数据，一秒几百万个点往上怼，单点故障？
想都不敢想。
什么叫高可用？
不是那些PPT里吹的玄乎概念。
哪怕出现这样的情况，一台机器冒烟了，机房断电了，甚至某个倒霉蛋把网线踢了，然而你的业务依旧在运行，监控曲线仍然在跳动，钱还在源源不断地哗哗进账。
这才是他妈的高可用。
数据不能丢，这是底线
时序数据库这玩意儿，写入量太凶了。
不像你，MySQL删库是能够跑路的，然而物联网的数据一旦丢失，那便是实实在在地丢失了，是无法补回来的。
所以第一道防线，就是多副本。
简单说，就是一份数据写三遍，存在不同的机器上。
通过运用Raft协议，借助那种“少数服从多数”的机制，以此来确保大家的数据都是一样的。
带头的没了，跟着的马上推选一位新的带头的出来，业务根本丝毫察觉不到有什么影响。
阿里云的那些人做事相当决绝，他们不但要存储数据，还必须确保做到即使你进行节点重启，内存中尚未写入磁盘的那部分缓存数据也不会丢失，这一切完全依靠WAL（预写日志）在那里支撑着。
别光想着活，还得想着怎么活得轻松
坦白讲，往昔之时，我格外厌烦那些每每会让你去搭建Kafka、Redis、Flink这一整套全家桶形式的方案。
不是说不好，是太特么累了。
你身为一个时序数据库，鉴于要达成高可用的目标，还必须去照应三四个兄弟系统，一旦出现问题，甚至连该先把锅甩向谁都不清楚。
这点我得夸夸TDengine那帮工程师，有点东西。
他们把流式计算、缓存这些功能直接内建到数据库内核里了 。
那就仿佛是你准备去用餐的时候，并非要先急急忙忙跑出去购买大米，接着费劲地去寻觅人来生火，最终还得自己动手去洗刷碗碟。
你直接点一份盖饭，啥都有了。
数据无需于各个系统之间来回倒腾，延迟得以降低了，可用性自然而然就提升上去了。
副本越多越好？
那是傻子干的事
你以为高可用就是疯狂堆机器？
三个副本不够？
来六个？
老板会杀了你。
硬件不要钱啊？
所以现在有了双副本 + 仲裁的玩法 。
数据只存两份，省了三分之一的存储成本。
但万一俩节点打起来，都说自己是老大怎么办？
这时候旁边那个不存数据的“仲裁者”举手投票，定生死 。
还有个叫“双活”的部署。
俩集群，异地，同时在线干活 。
若是你确实遭遇了诸如洪水、地震这般的情况，有一个机房处于了故障状态，然而另一个机房却依旧稳固地维持着运行姿态。
即便或许存有着几秒的延迟状况，然而对于容灾而言，这几秒，那可是关乎生死的关键所在。
电力系统的例子，很性感
我看过金仓数据库在一个省电力调度的案例 。
那才叫真·高可用。
连续不间断运行，全年之中需实现百分之九十九点九九九的可用率，且仅拥有四个小时的停机中断节点，每七天二十四小时持续运转不停歇。
进行压力测试之际，单日的并发连接数一下子达到了1024个，超出了设计值算出的2.4%。
他们怎么做的？
三层协同，数据层构建了3节点的共享存储集群，进而使得写入吞吐得到了40%的提升，跨安全区的同步，是隔着物理网闸来进行的，并且延迟被控制在了320毫秒以内。
还有更骚的操作：生产流量回放系统。
把过去30天的真实业务负载，在测试环境重新跑一遍 。
这相较于任何压力测试而言更为真实。在进行切换这个动作的时候，业务方处于睡觉的状态，然而系统却早已经于背后静悄悄地完成了主备倒换。
最后说点人话
高可用设计，不是堆砌技术名词。
是你得明白，你的业务到底能承受多少秒的 downtime。
一旦你着手开展智能工厂相关工作，一秒钟出现的延迟，就极有可能致使一个机械臂 malfunction，如此一来，你势必需要采用强一致性，借助Raft协议设置三副本，千万别在这方面节约那部分资金。
若你来处理车联网相关事宜，在偶尔出现丢失几条轮胎温度数据的状况下，问题并非十分严重，如此一来，便采用双副本加上异步同步的方式，既能节省费用，又能减少人力投入。
倘若你从事金融监控工作，那就别再多说无用的话语，直接开启两地三中心模式，即便是成本变为原来的两倍，也一定要保证数据不会丢失。
哦对了，还有那些信创的要求。
当下，国产的时序数据库所达成的成果着实蛮不错，诸如IoTDB、TDengine、金仓这类，针对龙芯、鲲鹏、麒麟系统的适配已然相当成熟了。
别再迷信国外那一套了。
终究，于情人节这个日子，哪怕无人与你一同度过，只要你的数据库依旧结实稳固，那就不算作是真正的孤单寂寞。
Comments NOTHING