登陆 | 注册 设为首页 | 加入收藏 | 联系我们
太和养老网
热词老年艺术  助老机构  养老系统  

中心区域北京 天津 河北 山西 内蒙古 辽宁 吉林 黑龙江 上海 江苏 浙江 安徽 福建 江西 山东 河南 湖北 湖南 广东 广西 海南 重庆 四川 贵州 云南 西藏 陕西 甘肃 青海 宁夏 新疆 香港 澳门 台湾 全国城市养老院目录 全国县市养老院汇总目录 太和AI作品展 太和养老艺术网AI作品展示

线上服务宕机时,如何保证数据100%不丢失?如何看待AWS宕机回应外部服务商出问题这件

 

2023/7/7 21:25:46 ('互联网')

本文目录

线上服务宕机时,如何保证数据100%不丢失

我们有很多的手段保证数据的安全,但是要保证100%安全这是不可能的。毕竟在系统运行的过程中,服务器可以出的问题千奇百怪,只能说尽可能的让数据尽可能的出出现丢失。

单纯的保证数据库本身的数据不丢失的话,最直接的方式就是通过建立主从库,实现数据的热备

一般情况下,小的系统我们并不会考虑数据的热备,一般只是在每天定时进行冷备而已,也就是设置一个定时器,然后到时间就同步数据。不过这样做的话,一单系统的数据库出现异常,那么我们的数据就会回滚到上一个备份的时间点,影响范围就会比较大。

因此,对于数据量大一点的系统,我们就会进行主从库的设置,不过通常情况下,我们做了主从库都会做读写分离。

现在不管是哪种数据库,都提供了数据库之间订阅同步的机制。以Mysql为例,我们先设置一个Master主库,然后在基于这个主库设置1个到多个Salve从主,从库通过在主库的SQLLog日志进行监听,一旦有SQL执行,就会记录一个二进制的Log,从库发现了这个Log,也会同时执行同样的操作,这样就实现了数据的热备。

但是,这种热备的机制并不能100%保证数据不丢失。因为,我们在写入主库的时候如果出现异常,导致SQLLog还没有记录,那么从库是不可能有数据记录的。当然,此后的数据不会有影响,因为这是从库会变为主库来记录后续数据。同样,如果主从库一起宕机,那也只有凉凉。

那么,为了让数据库的数据更加安全,就需要把数据保证的机制提前,不能单纯的依靠数据库来实现,那么我们可以加入队列来试试。

队列并不是针对于数据的,队列其实是用来保证消息的安全稳定的。自然,当请求没有被写入到数据库是,都是以消息的形态存在,我们就可以考虑队列来保证数据安全。

在数据库访问层,或者再靠前,到服务层,我们都可以加入MQ,让每一个请求都通过MQ来顺序的处理,一但数据库宕机了,MQ的执行就会失败,这时,失败的记录会被保存在MQ里面,并不会丢失,一但数据库重启,我们可以再次执行MQ中的消息,保证数据被成功的写入到数据库中。

具体怎么做呢?

首先,我们在插入数据库前,把插入的操作变为向队列对添加一个消息,然后,我们不同队列建立不同的消费者,消费者对队列的消息进行执行,再往数据库里面插入数据。

对于我们的服务层,我们只要把消息插入到了队列中,即视为成功,返回成功的消息。这样,虽然我们的数据处理会有一点点的延时,并且在事务的控制上难度会变大,可能需要建立补偿机制,但是我们的数据安全就更加高了。

这样是不是就安全了呢?

并不是的。消息服务器也可能会宕机,消息也有可能出现丢失的情况,所以并不能保证100%的安全。

如果我们还需要做的更好,我们还可以加上MongoDB来做日志

MongoDB是一个非关系型数据库,在我们现在的系统中应用非常广。最多的应用场景就是用来记录日志。那么,日志就是一个帮助我们避免消息丢失的有效方式了。

我们对服务层的每个请求报文,都用MongoDB记录请求的报文,再在请求处理完成返回结果的时候,记录一个消息的处理结果(成功或失败),这样,我们就能够很直观的看到每天发生的请求,处理的请求情况了。

当有服务处理失败了,不管是数据库的问题还是其他的问题,我们都可以对异常进行排查,然后再根据报文进行消息的重推。这样,我们的数据就会更加的安全了。

当然,即使如此,也不可能100%安全的,我们只能说尽可能的让系统更安全,只不过,安全的同时,付出的成功也是高昂的,我们需要来衡量是否有这个必要,当我们的系统确实足够大,用户量很大时,这么处理是有价值的,否则,那就是一种资源的浪费。

如何看待AWS宕机回应外部服务商出问题这件事

云服务厂商出现宕机的情况,不仅会给企业级的用户造成巨大的损失,而且还关系到了很多企业的生存,更是影响着千万亿普通用户的网络体验啊,所以还是希望AWS能够正视此次的宕机事故吧,不然真的是影响其未来的发展啊!

阿里云大规模宕机故障,网友表示还用还花呗吗

有这种想法的网友这脑子不太好使吧!

阿里云大规模故障和花呗有啥关系?云服务是给企业、个人建站等其他相关服务使用的,花呗是支付宝的金融业务,这两项除了都是阿里旗下外,完全是不相关的东西。并且这两项还都是两家公司的,阿里云是阿里云,花呗背后是蚂蚁金服,都不是一条线。

或许那些愚蠢的网友以为阿里的服务都是基于阿里云,现在大规模故障之后,支付宝以及花呗等一系列的业务数据丢失了!如果真是这么想,我都不知道该怎么喷人了。

如果真是这样,支付宝你还敢用?随便一下下你的支付宝数据就丢了,那你支付宝里的钱就没了,余额宝的钱怕也得没了,剩下支付宝中的资产被盗怕是你永远也追不回来了。平常不都是喊马爸爸牛逼嘛,支付领域第一,支付宝安全可靠,被盗能赔偿,怎么现在就又认为阿里云故障一下,花呗的业务数据都丢失了呢?光想着花呗数据丢失,咋不想想你支付宝的数据也是一样的服务器上,到时候得一起丢了。

所以,能提出这种想法的人,真是思路好单纯,简单的令人无地自容,都快2020年了,咋还有这样的人!

最后吐槽下阿里云,虽然市场占有率第一,但是这2年重大故障没少出,至于故障后的赔偿问题,也是毫无诚意,它是不会根据你企业的实际损失来给补偿,只会根据你购买服务的金额,然后现有发生故障的时间,折算出来赔偿金额来,这点钱,和企业真正的损失比起来,九牛一毛都不如。


感谢阅读,给点个赞鼓励下吧,欢迎关注【罗氏虫社】,谢谢!

系统的高可用性,大家是怎样理解的可以采用哪些解决方案

01什么是高可用性?

首先,我们需要理解什么是高可用?

维基百科的定义如下:

高可用性(英语:High Availability,缩写为 HA),IT术语,指系统无中断地执行其功能的能力,代表系统的可用性程度。是进行系统设计时的准则之一。

基本上来说,就是要让我们的计算环境(包括软硬件)做到full-time的可用性。在架构上来说,需要考虑如下设计:

1. 对软硬件的冗余,以消除单点故障。任何系统都会有一个或多个冗余系统做standby。

2. 对故障的检测和恢复。检测故障以及用备份的结点接管故障点。这也就是failover。

02 高可用的三种模式

1、主备模式

主节点工作,备节点处于监控准备状况;

当主节点宕机时,备节点接管主节点的一切工作;

待主节点恢复正常后,有两种恢复方式,一种是自动或手动方式切回到主节点;另一种是不切回,以前的主机沦为备节点,这种方式一般在云端采用。

数据的一致性一般是通过数据库同步方式解决。

案例:天翼云/华为云MySQL数据库服务的主备实例,如下图所示:

2、双活模式

主节点和备节点同时运行,通过全局负载均衡器负载分摊访问流量,当主节点机宕机时,备节点机立即接管它的一切工作,保证系统不间断运行;

主备节点一般是共享主节点的数据库实例,备节点数据库实例同步主节点实例,可提供只读服务。

案例:招商局的同城双活灾备系统就是该模式,可参考链接:

百年招商局大转型,“双云”混合继往开来

版权声明:

---------------------------------------------------------------


所有信息来源于互联网,本文的版权归原作者所有,不代表本网观点和立场。

本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容,请发送邮件至 81480447@qq.com 举报,一经查实,本站将立刻删除。



扫码加微信详细咨询太和智慧养老产品和平台服务!

 

养老资讯
助老机构介绍

评论
已有 0 条评论

最新评论

推荐养老院

您希望养老院位于
  • 不限
  • 东城
  • 西城
  • 崇文
  • 宣武
  • 朝阳
  • 丰台
  • 石景山
  • 海淀
  • 门头沟
  • 房山
  • 通州
  • 顺义
  • 昌平
  • 大兴
  • 怀柔
  • 平谷
  • 延庆
  • 密云
您希望的价格范围
  • 不限
  • 500以下
  • 500-1000
  • 1000-2000
  • 2000-3000
  • 3000-5000
  • 5000以上
老人的情况是
  • 不限
  • 自理
  • 半自理
  • 全护理
  • 特护

姓名

年龄

电话

全国城市养老院



关于我们 | 联系方式 | 网站地图 | 友情链接

Copyright 2010-2022 京ICP备18035644号-3 北京太和 版权所有