对 Web 系统来说，无非就是程序和数据，首先需要确定数据丢了没有，如果数据丢了，怎么调试都没有用，因此先恢复数据，保障系统运行永远是第一位的。...这个数量已经非常大了，没有办法通过手工恢复的方式完成了。这里有个判断，如果只影响到几个主题，通常我们都可以手工恢复的，如果影响的主题超过几十个，这个时候是没有办法手工恢复，只能找到原因让程序去做了。...Step 5 查询数据库的数据现在我们得从数据库查看了，因为没有办法确定到底是程序还是数据的问题。貌似在备份前 3 天的数据是好的，我们应该要把数据库的数据恢复下看看。...Step 7 把本地的备份数据恢复 1 条把本地备份的 1 条数据恢复到服务器上，然后刷下效果，看是不是就是因为数据丢了？太棒了，恢复的这条数据被显示出来了，主题正常了。...原来就是丢数据了，备份不应该是备份全部的吗？看来应该是恢复哪里或者某个表出问题了。Step 8 获得具体有多少数据被影响因为我们知道那个表现在有问题了， Select Count(*) 呗。
面试官：Redis持久化有了解吗？可以聊一聊吗？ 面试官心理分析：redis 如果仅仅只是将数据缓存在内存里面，如果 redis 宕机了再重启，内存里的数据就全部都弄丢了啊。...这个其实一样，针对的都是 redis 的生产环境可能遇到的一些问题，就是 redis 要是挂了再重启，内存里的数据不就全丢了？能不能重启的时候把数据给恢复了？...面试官：那你知道RDB和AOF这两种方式有什么区别吗？或者它们有什么优缺点？...Redis目前是支持同时开启这两种方式的持久化的，我们可以综合使用AOF和RDB两种持久化机制，用AOF来保证数据不丢失，作为数据恢复的第一选择；用RDB来做不同程度的冷备，在AOF文件都丢失或损坏不可用的是有可以采用...（同时Redis4.0之前Redis中RDB和AOF可以同时开启但是只会用AOF恢复，但是在4.0之后AOF中包含RDB全量增加记录的写操作）。 面试官：非常不错，我对你这边的情况还是比较满意的。
1 案例 主从集群有1个主库、5个从库和3个哨兵实例，突然发现客户端发送的一些数据丢了，直接影响业务层数据可靠性。...主从切换过程中，若原主只是“假故障”，会触发哨兵启动主从切换，一旦等它从假故障恢复，又开始处理请求，这就和新主共存，导致脑裂。 等哨兵让原主和新主做全量同步后，原主在切换期间保存的数据就丢了。...等新主上线，就只有新主能接收和处理客户端请求，此时，新写的数据会被直接写到新主。而原主会被哨兵降为从库，即使它的数据被清空，也不会有新数据的丢失。...主从切换完成后，数据会丢失吗？ 主库卡住 12s，达到哨兵设定的切换阈值，所以哨兵会触发主从切换。...这种情况下，新主库之所以会发生数据丢失，是因为旧主库从阻塞中恢复过来后，收到的写请求还没同步到从库，从库就被哨兵提升为主库了。
所以，我们不能经常对数据库执行全量备份。 一般来说，每天执行一次全量备份已经是非常频繁了。那这就意味着，如果数据库中的数据丢了，那只能恢复到最近一次全量备份的那个时间点，这个时间点之后的数据还是丢了。...假设我们每天凌晨用 mysqldump 做一个全量备份，然后开启了 Binlog，有了这些，我们就可以把数据恢复到全量备份之后的任何一个时刻。 下面我们做一个简单的备份恢复演示。...通过定期的全量备份，配合 Binlog，我们就可以把数据恢复到任意一个时间点，再也不怕程序员删库跑路了。 在执行备份和恢复的时候，有几个要点你需要特别的注意。...但是，这个恢复数据的时间是很长的，如果数据量比较大的话，有可能需要恢复几个小时。这几个小时，我们的系统是一直不可用的，这样肯定不行。 这个问题怎么解决？...也就是说，从库的数据是有可能比主库上的数据旧一些的，这个主从之间复制数据的延迟，称为“主从延迟”。正常情况下，主从延迟基本都是毫秒级别，你可以认为主从就是实时保持同步的。
养码人A表示心疼：哎，估计乐视在银行有贷款，银行拿乐视没办法，只能拿员工开刀了...... ? 养码人B也表示心疼：消息是真的，建行还发了公告，说会逐步恢复。乐视这是坑了员工啊...... ?...“ 用苹果的养码人B表示不服了：这怎么就是不好用了？这是钥匙搞丢了怪卖锁的了，这明明是一切都为了用户的安全和隐私。不能说你自己安全意识差你就怪苹果太注重安全吧。...养码人A反驳：怎么就不能吐槽下苹果了，就是不好用啊，安全性高体验就变差，对于对安全性有要求和偏好的，可能体验会好，但是我没有，所以我觉得体验不好。...CTO也写了代码，也算是程序员吗？架构师算是程序员吗？资深技术专家算是程序员吗？ 养码人B的答案：CTO是一种管理职级，程序员是一种职业，所以两者并不冲突。...为我们养码人的文采点赞好吗~ ? ? 不要聊税前，敢不敢聊税后？ 提问！现在肯谈税后工资的公司多不多呢？ 各位养码人纷纷表示： “你想多了。” “税太重了，几乎没人会谈税后。”
这个是我们真实遇到过的一个场景，确实是线上故障了，这个时候要不然就是修复 consumer 的问题，让它恢复消费速度，然后傻傻的等待几个小时消费完毕。这个肯定不能在面试的时候说吧。...所以如果你积压了几百万到上千万的数据，即使消费者恢复了，也需要大概 1 小时的时间才能恢复过来。...等快速消费完积压数据之后，得恢复原先部署的架构，重新用原先的 consumer 机器来消费消息。...这个情况下，就不是说要增加 consumer 消费积压的消息，因为实际上没啥积压，而是丢了大量的消息。我们可以采取一个方案，就是批量重导，这个我们之前线上也有类似的场景干过。...这个还有别的办法吗？没有，谁让你第一个方案执行的太慢了，你临时写程序，接入数据来消费，消费一个丢弃一个，都不要了，快速消费掉所有的消息。然后走第二个方案，到了晚上再补数据吧。
首先，我们把异步任务分为两种： 务必成功执行的 不成功就放弃 显然大多数时候都是第一种。那么当你把任务丢给线程池，你知道它完成了没有吗?...我推荐的做法是把任务投递到消息中间件，让它分发给消息消费者来执行(消费者可能是发送者自身)。 消息中间件可以要求消费者在完成任务后通知中间件，否则就重新分发消息，直到收到任务已完成的通知。...没有统计缓存响应时间 缓存一定快吗?我真的见过不快的。分布式缓存要经由网络，网络抖一抖，缓存抖三抖;还依赖运维，运维抖一抖，缓存抖三抖。此事之微妙，不可不察也。 留个心，设个超时，记个响应时间。...refresh是在异步加载新数据完成前，一直保留旧数据，能始终为数据库挡住压力，适用于高压情况。 各个应用实例的本地缓存是独立的，旧数据的作废依赖于过期策略。...复杂版的想法是好的，但注意，锁要设置超时(还记得我上文说的吗)，否则万一持有锁的实例发生问题，就全体耽误了。即使设了超时，也可能全体实例一直等待超时，浪费时间。
面试题 如何解决消息队列的延时以及过期失效问题？消息队列满了以后该怎么处理？有几百万消息持续积压几小时，说说怎么解决？...这个是我们真实遇到过的一个场景，确实是线上故障了，这个时候要不然就是修复 consumer 的问题，让它恢复消费速度，然后傻傻的等待几个小时消费完毕。这个肯定不能在面试的时候说吧。...所以如果你积压了几百万到上千万的数据，即使消费者恢复了，也需要大概 1 小时的时间才能恢复过来。...这个情况下，就不是说要增加 consumer 消费积压的消息，因为实际上没啥积压，而是丢了大量的消息。我们可以采取一个方案，就是批量重导，这个我们之前线上也有类似的场景干过。...这个还有别的办法吗？没有，谁让你第一个方案执行的太慢了，你临时写程序，接入数据来消费，消费一个丢弃一个，都不要了，快速消费掉所有的消息。然后走第二个方案，到了晚上再补数据吧。
大家好，又见面了，我是你们的朋友全栈君。 一、为什么要使用MQ？ 其实这里要讲的就是使用MQ的好处，MQ的的使用场景有很多，但是比较核心的有3个：解耦、异步、削峰 1....JMS规范走的有些系统要迁移需要修改大量代码 还有就是阿里出台的技术，你得做好这个技术万一被抛弃，社区黄掉的风险，那如果你们公司有技术实力我觉得用RocketMQ挺好的 kafka的特点其实很明显，就是仅仅提供较少的核心功能...MQ数据丢失问题 丢数据，mq一般分为两种，要么是mq自己弄丢了，要么是我们生产或者消费的时候弄丢了。...2）rabbitmq弄丢了数据 就是rabbitmq自己弄丢了数据，这个你必须开启rabbitmq的持久化，就是消息写入之后会持久化到磁盘，哪怕是rabbitmq自己挂了，恢复之后会自动读取之前存储的数据...这个还有别的办法吗？没有，谁让你第一个方案执行的太慢了，你临时写程序，接入数据来消费，消费一个丢弃一个，都不要了，快速消费掉所有的消息。然后走第二个方案，到了晚上再补数据吧。
候选者：我前公司的Redis架构是「分片集群」，使用的是「Proxy」层来对Key进行分流到不同的Redis服务器上 候选者：支持动态扩容、故障恢复等等......没找到，那只能使用「完全重同步」模式再次进行主从复制了 面试官：主从复制这块我了解了，那你说到现在，Redis主库如果挂了，你还是得「手动」将从库升级为主库啊 面试官：你知道有什么办法能做到「自动」进行故障恢复吗...候选者：首先它需要跟Redis主从服务器创建对应的连接（获取它们的信息） 候选者：每个哨兵不断地用ping命令看主服务器有没有下线，如果主服务器在「配置时间」内没有正常响应，那当前哨兵就「主观」认为该主服务器下线了...候选者：然后，以前的从服务器都需要跟新的主服务器进行「主从复制」 候选者：已经下线的主服务器，再次重连的时候，需要让他成为新的主服务器的从服务器 面试官：嗯...我想问问，Redis在主从复制的和故障转移的过程中会导致数据丢失吗...，此时「客户端」还没反应过来，还继续写向旧主服务器写数据 候选者：等到旧主服务器重连的时候，已经被纳入到新主服务器的从服务器了...所以，那段时间里，客户端写进旧主服务器的数据就丢了 候选者：上面这两种情况
所以如果你积压了几百万到上千万的数据，即使消费者恢复了，也需要大概1小时的时间才能恢复过来。 解决方案： 这种时候只能操作临时扩容，以更快的速度去消费数据了。...3.积压消息长时间没有处理，mq放不下了怎么办 如果走的方式是消息积压在mq里，那么如果你很长时间都没处理掉，此时导致mq都快写满了，咋办？这个还有别的办法吗？...解决方案： 这个就没有办法了，肯定是第一方案执行太慢，这种时候只好采用 “丢弃+批量重导” 的方式来解决了。...那肯定要了，落磁盘，才能保证别进程挂了数据就丢了。那落磁盘的时候怎么落啊？顺序写，这样就没有磁盘随机读写的寻址开销，磁盘顺序读写的性能是很高的，这就是kafka的思路。...（3）其次你考虑一下你的mq的可用性啊？这个事儿，具体参考我们之前可用性那个环节讲解的kafka的高可用保障机制。
国内一家著名的家电企业，多年来生产的产品一直价格高、质量一般，但市场却很火爆。有一段时间我一直用它的产品，只要别人有它也有的产品，我就买它的。...我遇到一家企业，由于自身产品问题导致市场被竞争对手抢占，到企业投诉的客户络绎不绝。企业采取的办法是集中精力整顿生产，试图在最短的时间内恢复产品质量。...这家企业犯了一个致命的错误：光准备“饲料”了，一回头却把“牛”丢了。 质量是企业的生命，这话不假，但市场是企业的空气。没有空气的生命，能够存活下去吗？...我问那家企业的质量主管，如果尽了最大的努力，你能保证企业的产品质量远远超过竞争对手吗？他说不能。不但不能，对手正在利用他们整顿的机会全力抢夺市场。...与此同时，内部迅速整顿生产，恢复产品质量。如果分配一下精力的话，我想，或许四分之三的精力应该放在市场上，才有机会打一场翻身仗。当然，这里有一个确保恢复产品质量的前提。
以上问题我都不能为你解决，但是！但是，我有几个办法可以帮你续命一口气，为了手上残破的 iphone 手机续一秒......... 废话不多说，进入主题，如何操作让你的旧 iphone 跑得更快更舒爽？...减少手机存储的大小，但是要注意微信的聊天记录处理！...点击 “备份”即可，详细都在我之前的文章里面写了。 顺便说一下，恢复备份就是点击 “恢复备份”，里面可以选择你之前的各种备份来恢复，很方便的说。 ?...五、减少手机存储的大小，但是要注意微信的聊天记录处理！ 因为根据专家解释，手机存储的文件过大会影响 ios 系统的正常流程运行！...，但又能保证你照片原图片存在，我想说的是，这是好事，但是呢，这里有个问题，对于微信这种拥有庞大的聊天记录的程序，如果使用这个方式的话，微信的图片基本是全丢了的。
3.备份时文件缺失 数据库运行在非归档，冷备时少了一个文件（别的同事做的备份），过了几天恢复数据库，用当时的冷备恢复，结果数据库起不来，丢失的文件还包括很多重要应用字典数据，没办法，重新输入这些字典数据...幸好是晚上，没有什么应用，及时恢复了数据库。 4.断电导致数据丢失 有一次大厦停电，通知半夜12点停电，我就懒得去动数据库了，没有备份，结果第二天早上，磁盘阵列启动不了了。丢了周五一天的数据。...我才发现不能想当地认为什么都不用做，这个错误让我更加记住了大家常说的“备份重于一切”。 5.误操作覆盖导出文件 imp用错了exp，结果把原来的dmp文件覆盖了。数据丢了，幸运的是数据不太重要。...所以，需要执行的每条命令，都要经过测试，确保其有确定的输出结果，然后才去执行它。如果你对某个命令没有把握，那永远不要去执行它。...2.执行备份并且进行备份检查 很多企业觉得有了备份就高枕无忧了，可是备份和“有效备份”还是两回事，我们一定要检查备份成功与否，备份是否有效，这样才能保证危急关头有“备”无患。
所以如果你积压了几百万到上千万的数据，即使消费者恢复了，也需要大概1小时的时间才能恢复过来。 解决方案： 这种时候只能操作临时扩容，以更快的速度去消费数据了。...2.消息设置了过期时间，过期就丢了怎么办 假设你用的是rabbitmq，rabbitmq是可以设置过期时间的，就是TTL，如果消息在queue中积压超过一定的时间就会被rabbitmq给清理掉，这个数据就没了...这就不是说数据会大量积压在mq里，而是大量的数据会直接搞丢。 解决方案： 这种情况下，实际上没有什么消息挤压，而是丢了大量的消息。所以第一种增加consumer肯定不适用。...3.积压消息长时间没有处理，mq放不下了怎么办 如果走的方式是消息积压在mq里，那么如果你很长时间都没处理掉，此时导致mq都快写满了，咋办？这个还有别的办法吗？...解决方案： 这个就没有办法了，肯定是第一方案执行太慢，这种时候只好采用 “丢弃+批量重导” 的方式来解决了。
如果数据库中的数据丢了，那只能恢复到最近一次全量备份的那个时间点，这个时间点之后的数据还是丢了。 也就是说，全量备份不能做到完全无损地恢复。 有没更好方法，少丢甚至不丢数据?...显示正在写入的Binlog文件，及当前的位置。 假设我们每天凌晨用mysqldump做一个全量备份，然后开启了Binlog，有了这些，就可以把数据恢复到全量备份之后的任一时刻。...很多情况下，数据库都不是突然宕机的，而是先繁忙，性能下降，最终宕机。这种情况下，很有可能主从延迟很大，如果我们把业务直接切到从库上继续读写，主从延迟这部分数据就丢了，并且这个数据丢失是不可逆的。...即使事后你找回了当时主库的Binlog也是没法做到自动恢复的，因为它和从库的数据是冲突的。...这个时候你就需要做一个选择题了 保证不丢数据，牺牲可用性，暂时停止服务，想办法把主库的Binlog恢复到从库上之后再提供服务 冒着丢一些数据的风险，保证可用性，第一时间切换到从库继续提供服务 能不能既保证数据不丢
，但是可能client还没来得及切换到新的master，还继续写向旧master的数据，然后旧master再次恢复的时候，会被作为一个slave挂到新的master上去，自己的数据会清空，重新从新的master...复制数据，就导致了我们之前在脑裂时候向旧master写的数据全部都丢失了。...min-slaves-to-write x min-slaves-max-lag y (要求y秒内至少有x个slave同步带可这个数据,比如x=1，y=10) 2.1减少异步复制的数据丢失 有了min-slaves-max-lag...这样脑裂后的旧master就不会接受client的新数据，也就避免了更多的数据丢失 上面的配置就确保了，如果跟任何一个slave（配置的x为所有从结点的数量）丢了连接，在10秒后发现没有slave给自己...上面两个参数保证了发生脑裂后多长时间停止新的写入，让我们数据丢失的损失降低到最少，这里脑裂状态持续的越久就会丢失越久的数据，因为他重启后会变成从结点，所有数据同步于新的master，原来的数据都丢了
而UDP就像是给邮政的信箱寄信一样，你寄出去的信，根本就不知道对方有没有正常收到，丢了也是有可能的。...udp发送接收过程 对于异常情况的处理 但如果不顺利呢？ 比如消息发到一半，丢包了呢? 丢包的原因有很多，之前写过的《用了TCP协议，就一定不会丢包吗？》有详细聊到过，这里就不再展开。...1663598420295 分段机制 但上面提到的都是怎么降低重传的概率，似乎重传这个事情就是无法避免的，那如果确实发生了，有没有办法降低它带来的影响呢？ 有。...当我们需要发送一个超大的数据包时，如果这个数据包丢了，那就得重传同样大的数据包。...最后 最近原创更文的阅读量稳步下跌，思前想后，夜里辗转反侧。 我有个不成熟的请求。 离开广东好长时间了，好久没人叫我靓仔了。 大家可以在评论区里，叫我一靓仔吗？ 我这么善良质朴的愿望，能被满足吗？
但是微信还是有高手，还是有能想办法的人，最终微信找到了解决方案。他们没有用任何的现成方案，而是使用了一种叫做内存映射（mmap()）的底层方法。...更多更深的原理，说实话我也不是看得很懂，就不跟大家装了。但关键是，有了这一层内存作为中间人，我们就可以用「写入内存」的方式来实现「写入磁盘」的目标了。...而刚才我也说过，这种场景的特殊性在于，导致程序崩溃的文字往往是刚刚被记录下来，程序就崩溃了，所以如果采用异步处理的方案，就很有可能在文字还没来得及真正存储到磁盘的时候程序就发生了崩溃，那就没办法把它恢复出来进行分析了...；而 MMKV，没有这种自动的备份和恢复，那么当文件发生了损坏，数据就丢了，之前保存的各种信息只能被重置。...不过正好 MMKV 所要记录的这些要显示的文字，也并不是不能丢失的内容——真要是丢了就丢了呗，反正是崩溃日志，丢了就不要了，我下次启动程序之后继续记录就是了——所以既然要求必须高频写入而导致很难实现自动备份
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
