宕机怎么读,真的会导致大脑迟钝吗

宕机怎么读，真的会导致大脑迟钝吗？

我严肃地告诉你 会的，不骗你。你知道看这些黄色网站的危害吗？

对于‘黄 赌 毒’我们都知道，这三个一直都是人们排斥的毒瘤。那你知道‘黄’要排在第首位？

古人云:万恶淫为首，百善孝为先。根据字面意思可以理解为世界上所有的罪恶之中，淫乱要排在最首位。

随着现在时代的发展进步“黄色”从古时候的书籍到九十年代的录影带、VCD光盘再到现在的网络网站、手机软件。这种黄色的毒瘤一直充斥在人们的生活当中而且在逐步扩大。

现在这类黄色网站、软件我们专门组建网络警察，对网站进行全方位的封禁。然而，这些成人网站往往都是在境外注册，所使用的都是虚拟ip而更换域名成本很低。再加上成人网站的用户群体量源源不断，会产生超多的点击量，所以投放不良广告的广告商就更加舍得投入，完全可以让成人网站能够频繁更换域名。这就导致就算再怎么禁绝，国内的成人网站都如同野草般，烧不尽、吹又生。

这些网站会给我们带来哪些危害呢？

这些色情网站经营主要的经济来源是充值会员和大量投入违法广告，而这些广告的内容大多都是赌博链接。上面的内容充斥着违法赌博的金钱诱惑，一旦你点入链接将会深陷其中，无法自拔。到最后搞得倾家荡产，甚至家破人亡。

色情手机APP的危害更是让人防不胜防！当你安装这些违法APP后你的手机可能会被监听，号码可能会被倒卖。手机里一些比较隐私的数据会被泄露甚至会被敲诈勒索。

手机里的财产会被骗取。现在这些APP都是要充值会员才能观看，当你充值成功后可能APP会被清除，等于白交了钱财。

当你在浏览色情APP时你的手机后台可能已被链接操纵，手机里的钱财会自动转移出去，造成重大损失。

其次这些黄色网站对人的心理、生理都有严重的危害。在网站上存在很多不符合社会法则与公德的剧情，如果长期观看不但会容易导致心理扭曲有些人还会效仿剧情里的情节，产生违法犯罪的行为。现在这种案例很多。可以说百害而无一利。

如今已加大对黄色网站、app的打击力度，国家也有投诉网址，如有发现不良网站应立即向有关部门进行汇报。只要每个人不去看它，让其无利可图必然能彻底禁止。

常看这些不良网站会让你的心理扭曲，而且会让你淫欲过度，导致精神萎靡、肾虚、白发、腰疼、视力下降、记忆力减退。

当你记忆力减退后你做什么事情都会迟钝。

Java程序员面试中容易被问哪些问题？

不请自来

面试总结——Java高级工程师

面试前面也总结了一和二， 这第三篇可能更偏向于是内心的独白篇和面试技巧总结吧.....

一、独白

之前也面试别人，现在轮到自己找工作，怎么说呢，每个面试官的看法不一样，面试的方式就不一样，比如我面试别人我喜欢问项目中他用到了那些，然后针对用到的技术去问一些问题，或者说对于某些场景的一些技术实现方案是我特别喜欢问的，比如当你的接口服务数据被人截包了，你如何防止数据恶意提交？ 相对来说，Java的底层和基础会问的少一点，当然问的少不是代表不问，而是说侧重点在于你的所做过的项目和你的设计思路如何。当然，懂基础和底层更好，这样能让你知其然，更知其所以然，写出来的代码和程序更具有健壮性和可维护性。所以说，基础还是很重要的。

现在轮到自己出去面试，怎么说呢，其实还是挺紧张的，原以为自己不会因此紧张或者焦虑，实际上，还是有的，在没找到合适的工作的时候，甚至晚上有点睡不着觉，总觉着有什么事压在心头，睡觉都不安心。既然睡不着，那还是看看资料吧，我有个习惯，睡前看点问题，第二天早上就能想到答案，睡前记点资料，第二天早上就能记得特别深刻，不说废话了，直接进入正题吧。

二、面试技巧

1、背熟你的简历

原因：面试的第一个问题，一般都是让你简单介绍下你自己，或者介绍一下你最近的项目，而一个面试者，如果连自己的简历都无法熟知，对里面提到的项目、技术都无法描述清楚的话，我想没有哪家公司会接受这样的，哪怕你是超级人才，你自我表述不行，估计也会为此头疼，所以，切记：一定要背好自己的简历，不要求你能全部记下，至少要熟记你最近所待过的两家公司，这两家公司里面你做过的项目，你负责的模块，项目里面用到的技术以及相对应的技术实现方案（这个尤为重要）。

2、深入了解并熟记部分Java基础知识

原因：大部分公司无论面试初级还是高级，无论是笔试还是面试，都会问到一系列基础题，这些基础题大概涵括jvm、字符串、集合、线程等等，如果说每一个让你死记硬背你肯定记不住，那么就是理解中记忆了，拿jvm来说 ，如果让你谈谈你对jvm的理解， 那么你首先得知道JVM有哪些结构组成，每个结构用来做什么的，然后考虑一个Java对象从创建到回收，如何途径JVM这些结构的。如果你从这些方面来综合记忆，相信事半功倍，并且你理解的更透彻。 至于如果让你谈集合，举例List集合下面ArryList、LinkedList、Vector等集合的区别，那么同样的方法，你需要理解每一个的结构组成是什么，你才能知道他有什么作用，这样你在平时的用法上会更精炼，而且在面试过程中，也不至于哑口无言。

3、保持自信心和沉重冷静的心态

原因：面试过程中，自信是少不了的，相信你可以， 面试的路上可以自己对自己说一句： I belive I can ! 反正我就是这么做的，自我的心里暗示吧，其实面对面试官的时候，你自信的状态也会让面试官觉得你是个很有底气的人，至少从感觉上会给你打个高分。另外还有就是保持沉重冷静，如果是让你提供技术方案或者说说某个技术原理，没必要一紧张一咕噜的什么都说，你可以对面试官说：我先想想，然后自己组装记忆中的知识，组装下语言，有条理的说出来，这样能更好的表现你的才能，不是吗？ 面试谁都会紧张，我也会紧张，有时候明明记得的知识点忘了，没关系，大胆的说忘了，或者直接说不知道。 要记住，有部分不知道没关系，如果全都知道，那你应该是CTO级别了（开个玩笑）。

4、尽量记住面试过程中你回答不出来或者回答存在不妥的问题

原因：面试失败了没关系，毕竟每个公司的要求不一样，问的问题和你擅长的方面可能有所出入，但是请记住一点：面试过程中那些你回答不出来问题，或者你自己感觉回答不太准确的问题，自己记下来，如果不会的，你可以当场问问面试官有没有好的解答，如果面试官不愿意告诉你（一般是基础方面面试官就懒得答你），那么你就自己回家慢慢查资料，如果是某些特定的技术，也可以自己写写案例什么的，毕竟知识点就那么多，问题百变，原理不变，面试也是一个学习知识的过程，让你了解大部分公司目前需要或者要求的技术。这次不知道，下次就知道了

5、去面试之前，最好先了解你要去面试公司的情况（包括产品、项目情况）

原因：俗话说，知己知彼，百战不殆，面试就是一场战斗，你需要了解你面试公司基本情况，包括岗位要求，这样你就能大概知道你需要面试的这家公司的技术要求情况。 为何让你去了解这家公司的主营产品和项目呢，就是让你大概了解这家公司的一个技术架构的情况，包括你可能对他们的一种实现方式提出质疑和疑惑，相信面试官很愿意帮你解答这些问题的。这样你既图了表现，也学到了知识，何乐而不为。

6、合理安排你的面试时间（如果有多家公司的面试机会，尽量把你想去的公司放到最后去面试）

原因：估计很多人都不理解这个，可能大部分的人对于如何安排面试时间比较迷茫，随意安排。可是这里有个技巧，如果同时有多个面试机会，你把你最想去的公司放到最末尾去面试，这样你经历过了前面的这些公司筛选，如果成功了是个机会，如果没成功，也是为最后做铺垫。 不过这里就需要考虑两点：1、你需要记住你投简历的公司和基本情况（这说明你不是海投的） 2、如果记不住，那么可以先应答一个时间，后续了解公司信息之后，通过邮件或者其他方式与其约定，调整面试时间。而且建议安排一天的面试公司不要超过两家，最好的是上午一家，下午一家，这样你能有充足的时间调整状态。

三、面试题基础总结

1、 JVM结构原理、GC工作机制详解

答：具体参照：JVM结构、GC工作机制详解，说到GC，记住两点：1、GC是负责回收所有无任何引用对象的内存空间。 注意:垃圾回收回收的是无任何引用的对象占据的内存空间而不是对象本身，2、GC回收机制的两种算法，a、引用计数法 b、可达性分析算法（ 这里的可达性，大家可以看基础2 Java对象的什么周期），至于更详细的GC算法介绍，大家可以参考：Java GC机制算法

2、Java对象的生命周期

答：创建阶段 、 应用阶段 、不可见阶段 、不可达阶段 、收集阶段 、终结阶段、 对象空间重新分配阶段等等，具体参照：Java 对象的生命周期

3、Map或者HashMap的存储原理

答：HashMap是由数组+链表的一个结构组成，具体参照：HashMap的实现原理

4、当数据表中A、B字段做了组合索引，那么单独使用A或单独使用B会有索引效果吗？（使用like查询如何有索引效果）

答：看A、B两字段做组合索引的时候，谁在前面，谁在后面，如果A在前，那么单独使用A会有索引效果，单独使用B则没有，反之亦然。同理，使用like模糊查询时，如果只是使用前面%，那么有索引效果，如果使用双%号匹配，那么则无索引效果

5、数据库存储日期格式时，如何考虑时区转换问题？

答：使用TimeStamp , 原因参照：Java编程中遇到的时区转换问题

6、JavaObject类中有哪些方法？

答：Object有哪些方法

7、HTTP协议，GET和POST 的区别

答：浅谈HTTP中GET和POST的区别

四、线程、设计模式、缓存方面

1、SimpleDataFormat是非线程安全的，如何更好的使用而避免风险呢

答：关于SimpleDateFormat安全的时间格式化线程安全问题

2、如何看待设计模式，并简单说说你对观察者模式的理解

答：1、设计模式有神马用2、观察者模式类图及实现

3、集群环境中，session如何实现共享

答：1、Java集群之session共享2、session多服务器共享方案，还有一种方案就是使用一个固定的服务器专门保持session，其他服务器共享

4、分布式、集群环境中，缓存如何刷新，如何保持同步？

答：A、缓存如何刷新？1、定时刷新 2、主动刷新覆盖，每个缓存框架都有自带的刷新机制，或者说缓存失效机制，就拿Redis和 Ehcache举例， 他们都有自带的过期机制，另外主动刷新覆盖时，只需获取对应的key进行数据的覆盖即可

B、缓存如何保持同步？ 这个redis有自带的集群同步机制，即复制功能，具体参考：基于Redis分布式缓存实现，Ehcache也有分布式缓存同步的配置，只需要配置不同服务器地址即可，参照：Ehcache分布式缓存同步

5、一条sql执行过长的时间，你如何优化，从哪些方面？

答：1、查看sql是否涉及多表的联表或者子查询，如果有，看是否能进行业务拆分，相关字段冗余或者合并成临时表（业务和算法的优化）

2、涉及链表的查询，是否能进行分表查询，单表查询之后的结果进行字段整合

3、如果以上两种都不能操作，非要链表查询，那么考虑对相对应的查询条件做索引。加快查询速度

4、针对数量大的表进行历史表分离（如交易流水表）

5、数据库主从分离，读写分离，降低读写针对同一表同时的压力，至于主从同步，MySQL有自带的binlog实现 主从同步

6、explain分析sql语句，查看执行计划，分析索引是否用上，分析扫描行数等等

7、查看mysql执行日志，看看是否有其他方面的问题

个人理解：从根本上来说，查询慢是占用mysql内存比较多，那么可以从这方面去酌手考虑

五、设计方案相关

面试还会问到一些关于设计方案相关的问题，比如

1、你的接口服务数据被人截包了，你如何防止数据恶意提交？

答：我们可以在接口传输参数里面设置一个业务编号，这个编号用来区分是否重复提交。这样即使数据被抓包了，对方也无法区分每个字段你的含义，这时，这个业务编号的作用就来了

2、假设服务器经常宕机，你从哪些方面去排查问题？

答：这个就留个各位看官补充了，可评论回复

总而言之该看的还是得看，还学的还是得学。再次强调，基础很重要！面试技巧同样很重要，还是那句话：祝愿各位看官都能找到心仪的工作吧~~

另外，奉劝大家不要频繁跳槽，这些知识点能提升固然好，不要盲目跳槽，找工作很累的，而且没有哪家公司喜欢频繁跳槽的员工

Java程序猿跳槽应该学哪些方面的技术

互联网产品、大型企业级项目常会用到的：

并发处理技术。具体到Java上通常是涉及java.util.concurrent、并发锁机制、NIO等方面，当然最近比较火爆的Netty框架也可以作为高并发处理的备选方案之一，这需要对Java的线程调度机制有着比较深的理解。不过这些可能会涉及并发控制的对象（比如reentrantlock等）只能存在于一个JVM里的问题，一旦系统规模大到需要部署多个JVM来处理并发的情况，则需要采用共享session的技术（比如spring-session），或者尽可能将系统后台设计为无状态的服务，这需要对RESTful有着较深的理解。

高可用、负载均衡技术。互联网产品、企业级应用通常要求一年里的Downtime控制在很小的范围内，这需要足够的高可用和负载均衡架构来支撑，这个一般和Java技术本身没太大关系，但却是一名初级程序员向高级程序员甚至是架构师CIO进阶的必备技术，因此可以适当了解一下Nginx、HAProxy等对这方面的支持。另外现在最“时髦”的做法是将应用docker化，配合ETCD、kubernetes等工具在容器的层面上实现高可用和负载均衡，当然这需要看实际的需求，最时髦的不见得是最适用的，要考虑构建成本。

缓存技术。缓存应该是大型系统中或高并发条件下提高响应速度的亘古不变的真理（虽然也看到过淘宝搜索商品功能采用的大数据处理技术实现的零缓存的文章，但能达到淘宝的体量和技术水平一般不太可能），群号：468897908高级架构群 备注好信息！这方面的工具太多了，ehcache、memcached、redis……从Java的角度来讲，需要了解的一是Java对这些工具的连接器，二是缓存技术背后的JSR-107标准，可以参考spring-cache的实现，阅读一下源码加深理解。

异步处理技术。这通常也是抵消高并发的处理手段之一，从Java的角度看最简单的异步处理就是新启动一个异步线程，这同样也需要对Java的线程调度有所了解，当然也可使用Spring中的@Async之类的也可以简单实现异步线程的处理。如果是非常消耗资源的业务处理，简单的异步线程是满足不了需求的，这就需要一些消息中间件来做这些异步处理了，消息中间件有很多，activemq、rabbitmq、kafka……需要了解的是Java对这些中间件的连接器。不过异步处理中最关键的是事务保证的问题，这可能需要对事务的两步提交有所了解。

在这里我有一个专门为跳槽JAVA开发人员想要跳槽准备的一个线路图：

一共分为5大专题：

工程化专题：

源码分析：

分布式/高可用/高并发专题：

双十一架构：

性能优化：

如何实现分布式系统的高可用性？

职场新兵的指南：关于高可用系统建设的一些思考

在参与公司几个多数据中心项目的容灾架构设计后，积累了一些高可用和多数据中心容灾的一些思考，希望总结和分享出来和大家一起学习。

可用性衡量指标我们做软件系统核心是服务于业务，构建高可用系统本质也是为了让业务的服务质量提供，因为在构建高可用系统之前，我们需要根据业务特性确认我们系统需要怎么样的高可用级别，也就是需要一个指标度量我们系统的可用性。

可用性度量的指标有以下几个：

MTBF（Mean Time Between Failure），平均故障间隔，代表两次故障的间隔时间，也就是系统正常运转的平均时间。这个时间越长，系统稳定性越高。MTTR（Mean Time To Repair），故障的平均恢复时间，也叫平均故障时间。这个值越小，故障对于用户的影响越小。但 MTBF 和 MTTR 这两个指标中的故障不仅仅是IT系统宕机故障，也包括了性能问题和人为的错误。甚至USITS一项关于大型互联网服务的研究发现，运维配置错误是导致服务中断的首要原因，而硬件故障（服务器或网络）仅导致了 10-25% 的服务中断，但如何避免人为错误并不在今天的讨论当中。

所以，在针对数据中心的容灾，我们可能用到更多地是RTO和RPO这两个指标：

RTO(Recovery Time Object)，恢复时间目标，RTO是反映数据中心业务恢复的及时性指标。RPO(Recovery Point Objective)，复原点目标，指数据中心能容忍的最大数据丢失量，是指当业务恢复后，恢复得来的数据所对应时间点，RPO取决于数据中心数据恢复到怎样的更新程度，反映数据中心恢复数据完整性的指标。

一般我们对现有系统做可用性改造时，可以先看看现有系统的基准值是多少，然后根据业务目标，确定要提升到多少来改善。

高可用改造层级在和业务确定好可用指标后，接下来就需要对系统做高可用改造，从容灾级别可以分为三个层面：

基于Region(地理区域)的高可用架构同城多Zone的高可用架构单Zone多实例的的高可用架构注：这里Region表示地区，一般是指行政单元比如地级市，Zone表示可用区，指电力和网络相互独立的物理区域

从软件架构的角度来看，针对可用性改造可以分为四个部分：

DNS服务负载均衡(LB)应用服务数据库/中间件其中，DNS服务和负载均衡都是无状态的，数据库和中间件则是有状态的，而应用服务根据业务逻辑不同可能是无状态也可能是有状态的。

单机房多实例的的高可用架构这种架构是最简单的，一般这种架构只有一个LB网关，通过LB转发到下游的应用服务，应用服务可以通过服务发现的方式做成多副本从而实现多活，比如可以用k8s部署应用服务，配合存活探针检查和k8s的service服务发现，可以轻松实现无状态应用的多活。如果你的服务不基于k8s部署，也可以基于微服务框架部署在多台主机上实现应用多活，只要实现服务发现、存活探针检查和自动的流量切换就可以了。

但对于有状态的，比如数据库和中间件，仅仅依赖服务发现和流量切换并不能解决问题，因为数据在多副本之间需要做同步。因此针对数据库或中间件的高可用方案基本都是需要专门设计，因为除了流量切换还要解决数据同步问题。这部分在后面数据库和中间件高可用解决方案在单独展开。

同城多机房的高可用架构同城多机房（多AZ）容灾一般通过 BGP 实现单IP多线网络，然后机房之间通过专线相互打通物理网络，当出口流量出现故障时，可以通过 BGP 在路由层切换报文转发表来实现线路切换。架构图如下：

在数据链路正常的情况下，机房1，2会分别向路由宣告自己的路由表：机房1：地域AS -> 运营商AS -> 机房1 AS机房2：地域AS -> 运营商AS -> 机房2 AS

在机房1出现故障和运营商边缘（接入）路由器断开的时候，机房2会向运营商AS宣告连接机房1的最短路径从而让流量转发给自己：地域AS -> 运营商AS -> 机房2 AS -> 机房1 AS

如果对路由器BGP协议不是很了解的可以参考BGP的wiki

基于地理区域的高可用架构如果我们要做基于地理区域级别的高可用，那么我们需要DNS智能路由和跨地域的云连接。

DNS智能路由DNS服务结合存活探测可以实现跨地域流量切换。当存活探测发现后端 LB 不可用的时候，可以直接修改DNS解析，使其失效。但需要注意 DNS 协议切换一些延迟，生效时间在15分钟~30分钟（RTO），因此 DNS 一般只用于跨地域的 LB 的高可用，只有当整个地区的 LB 不可用的时候才会被启用。

我们知道跨地域的故障可以根据智能DNS协议来切换流量到不同的LB中，那么DNS服务本身是如何做高可用的呢？DNS 服务做高可用一般是基于 Anycast 和路由协议来实现，比如 BGP 或 OSPF。和同城多机房的高可用架构一样，通过路由协议实现单IP多线的网络架构来实现容灾切换。Anycast 网络允许网络上的多台服务器使用相同的 IP 地址或一组 IP 地址, 通过 BGP 的路径选择算法改变路由的选择，从而使失效的DNS服务器节点下线，或者实现智能路由。不过 DNS 服务做了高可用并不一定就万无一失了，2021年10月4日的 facebook 全球死机事件就是 BGP 配置错误导致了 facebooK 的 DNS 全部失效了。所以，像开头说的，高可用系统架构只是解决了系统硬件故障，但人为配置错误并不能避免。

云连接跨地域的云连接可以是基于骨干网的专线，也可以是VPN。通过云连接将处在不同地域的子网连接起来构造一个互联互通的企业网。专线相比VPN网络传输会更稳定些，安全性更高，但价格也会更贵，成本更高。

数据库及中间件的高可用方案数据库和中间件的容灾是一种典型的有状态服务应用的场景，其核心是数据复制和同步。前面说到的两个指标 RTO 和 RPO 就是围绕数据容灾来描述的，如果我们是双活架构那么RTO就是0，如果是主备那么RTO就是主备切换所需的时间；如何我们的数据复制采用完全同步的方式，RPO就是0，如果采用异步复制，那么RPO就是数据复制之间的时间差，如果是快照，那么RPO就是快照产生备份数据和。

数据复制数据复制按照leader可以分为三种：单领导者（single leader，单主），多领导者（multi leader，多主） 和 无领导者（leaderless，无主）。单主和多主都属于主从架构，从节点通过复制主节点的日志或变更流(change stream)来同步数据，但在使用场景上两者存在比较大的不同，多主架构一般被用于地理位置上的多数据中心的容灾和就近服务，而单主架构一般用于单数据中心，因为多主架构给整个系统带来的复杂度是很高的，我们需要处理数据冲突，这会给整个系统带来复杂性并降低性能。架构设计核心是要解决问题，因此本质上是一种取舍和balance，在架构设计的时候要视业务和场景而定。

单主架构单主架构就是我们常说的主从架构，是分布式架构中最简单的架构，只在 leader 节点做读写操作，follower 节点提供读操作。从库复制主库通常通过变更日志实现，这种变更日志既可以是预写日志(WAL)，也可以是复制逻辑日志。常用的数据库的数据复制:

Kafka的kafaka MirrorMarkerMySQL的 binlog 主从复制PostgreSQL的 WAL 主从复制多主架构多主架构在主从数据同步逻辑上和单主架构是一样的，区别核心在多个主节点写入数据的时候如何进行数据同步。一般引入多主架构其中一个原因是解决跨地域数据同步问题，比如在单主架构下，一个在广州的用户在写入数据需要需要传输到北京的主节点上，那么性能就会比较差了。另一个原因则是多主的故障容忍要大于主从，比如在两个主节点的情况下，其中一个节点出故障的时候另一个节点并不会受到影响，只会影响一半的用户，而主从架构在从节点切换完成之前是全用户故障的。我们可以先从最简单的，两个主节点来讨论。在双主的结构下，核心要解决的就是写入的时候的数据冲突问题，如下图所示：

在解决数据冲突的时候通常会采用以下的一些办法：

最简单的方式就是采用同步的方式写入数据，即数据写入成功需要等待其他主库解决冲突之后，这样就将多个主库写入变成串行执行了，也就失去了多主库的核心。通过分库的方式来避免冲突，比如请求通过统一的路由让a用户数据都读写在A库中，而b类数据读写在B库，其实这样本质类似于将数据库以多分区的形式存放在多个地区，只是a库会通过数据复制在同步到b库。只保证所有副本最终一致性，通过全局唯一ID或全局时钟确定最后更新的数据才写入。但是这种方法在异步的情况下会导致一部分中间数据丢失。除了要解决数据冲突，多主在数据复制的时候还需要解决节点复制传播的顺序，也就是复制拓扑(replication topology)。对于多主复制，常见的复制拓扑主要有三种：

环型拓扑架构(circular topology)，即一个数据节点将数据复制给相邻的节点，依次循环一周。星型拓扑架构(star topology)，所有节点围绕着一个中心节点进行数据复制和交互。全拓扑架构(all-to-all topology)，即所有节点相互之间都会进行数据的复制和交互，常见的比如 gossip 协议。

在多个主节点进行数据复制和传播的时候，由于会经过多个节点，节点之间需要识别携带其他节点的变更信息，比如每个节点添加有一个唯一ID标识其已经过的节点，这样才不会造成无休止的死循环无休止的传播。

无主架构在无主架构中每个节点都可以对外提供服务，从设计理念上可以看出无主架构天生就是为可用性而生，不过知道CAP理论的都知道，可用性和一致性不能兼得，无主架构是个典型的AP模型，其牺牲了强一致性用最终一致性代替。无主架构中最出名的是 AWS 的 Dynamo，像 Cassandra 这种采用和他类似的无主架构的都被成为类Dynamo。Dynamo 采用Gossip协议来做复制数据，任何一个节点收到数据后会向其他节点异步地复制数据。那么 Dynamo 是怎么保证数据最终一致性的呢？Dynamo 使用 W + R > N 这个公式保证，R代表最少读取的节点个数，W代表最少写入的节点个数，N为数据副本数，这里的副本数并不是实际的物理节点，因为 Dynamo 使用的一致性 hash。

比如N有3个节点，R是2，W也是2，那么客户端向集群写入数据的时候只有在2个节点写入成功后才会返回给客户端，这个过程是同步的，剩下的两个节点则是异步的，在读数据的时候，必须读到2个节点，并取2个中最新的数据，可以看出这样肯定可以读到最新的数据。

当出现数据冲突的时候 Dynamo 通过引入向量时钟解决数据冲突：

向量时钟通过带上其他节点的向量时钟来确定偏序关系，按图上例子三个节点P0，P1，P2，初始三个节点都是(0,0,0)

首先，P0写入在 a 写入数据，P0 的向量时钟为(1,0,0)当P0把时钟信息传播到 P1 的时候，对应的是时间点 b，P1 的向量时钟是(1,1,0)，这时候 P1 节点如果有个c写入，那么他的向量时钟是(1,2,0)，c的向量时钟里面的元素均大于等于 a，所以我们可以知道 c 时刻大于 a。这时候 P1 把时钟信息传播 d，向量时钟是(1,2,1)，写入数据 e 的数据时钟是(1,2,2)，这个信息传回 P0 后变成 g 时刻，向量时钟是(3,2,2)在这里我们可以看到，a -> b -> c -> d -> e -> g 这个逻辑顺序是成立的，而在向量时钟上表现就是后一个所有元素都大于或等于前一个时间点。但 f 和 c, e 的先后顺序关系是不确定的，在没有全局时钟的情况下你并不能知道谁先谁后，而在向量时钟上表现就是 f 不是所有元素都大于等于 c 或 e。因此，其实向量时钟表示为:

if V(a) > V(b) then a -> b

V(a) > V(b), 表示a向量的所有坐标元素大于b向量的所有对应坐标的元素，a->b 表示 a 到 b 存在事件顺序。

向量时钟只能解决最终一致性（收敛）问题，如果数据在达成最终一致性之前产生版本冲突，Dynamo 会将冲突版本返回给客户端，由业务自行判断。除了交由客户端判断，我们也可以采用“最后写入胜利（LWW, last write wins）”的策略，在数据生成的时候通过带上时间戳，最后比较两个版本的时间戳谁新以谁为准。

Dynamo 检测数据不一致用的 MerkleTree，MerkleTree 是通过一个 hash 树来计算每部分的数据，父节点是子节点数据的 hash，只要有一块数据变动了，最上层的根节点的hash就会改变，然后可以通过逐层递归的方式找到目标节点，查询时间复杂度是o(log(n))，如下图：

更多详细的 Dynamo 可以参考原论文，这是国外老哥的一篇论文笔记：

数据复制的几种方式前面说了数据复制的几种架构，那么具体数据复制的形式有哪些呢？这里根据数据库复制数据的主体不同分为四类：

基于语句(statement)的数据复制基于逻辑日志(行)的数据复制基于预写日志(WAL)的数据复制基于触发器的复制基于语句复制直接基于数据库的语句进行复制，MySQL 5.1 版本前都是基于语句进行复制，基于语句的主从复制下 MySQL 会将 SQL 变更语句写入 binlog 中，然后同步给从节点让其更新，基于语句的复制主要简单，而且传输数据量少，但其可能会存在不安全语句，而且每次更新都只能串行，特别是某些语句比如 INSERT ... SELECT 会因为锁比行复制慢更多。PostgreSQL 的 pgpool-II 也是一种基于语句复制工具，但其本身相当于数据库的 Proxy，而不是数据库自身提供的CDC。

复制逻辑日志(行)逻辑日志是针对语句复制提出来的，因为基于statement的复制存在诸多问题，比如事务没办法并行复制，只有等待一个commit才能复制另一个，性能差。因此另一种，是以行为颗粒度基于逻辑日志的数据方式，经典代表就是 MySQL的binlog(row)格式。其对数据库表的写入记录：

对于插入的行，日志包含所有列的新值。对于删除的行，日志包含足够的信息来唯一标识被删除的行，这通常是主键，但如果表上没有主键，则需要记录所有列的旧值。对于更新的行，日志包含足够的信息来唯一标识被更新的行，以及所有列的新值（或至少所有已更改的列的新值）。复制预写日志(WAL)很多数据库在写数据的时候为了磁盘顺序读写优化和事务性会引入预写日志(write ahead logs,WAL)，因此一些数据同步方案会尝试利用 wal 特性来做数据复制和同步。比如 PostgreSQL 9.0之后的 PITR(Point in Time Recovery) 就是基于 WAL 做主从复制。 PostgreSQL 的预写日志复制传输提供两种：存档式(archive)和流式(streaming)。存档式就是等一个WAL文件写完后，再拷贝从节点；流式则是写完一条WAL记录就通过TCP直接传给从节点。存档式存在数据延迟较大，流式则再主节点崩溃时从节点存在丢失数据的可能。

PostgreSQL Archive Replication

PostgreSQL Streaming Replication

基于触发器的复制

上面讲的那些复制方式都是数据库系统提供的，比如基于语句和逻辑日志的复制是在数据库的 server 计算层来做，预写日志(WAL)则是在存储层做，而触发器是数据库系统系统的将自定义的程序注册进数据库让其在数据变更时自动触发。由于是由外部程序对变更进行捕捉，因此他的灵活性是最高的，像多主复制的冲突解决方案大部分都是基于触发器实现，比如 PostgreSQL 的 bucardo 就是基于 pg 的触发器来做多主的数据复制。

小结整篇小作文洋洋洒洒写了近一万字，从系统架构、各层级组件的高可用到数据复制拓扑，希望可以给大家一个相对比较完整的视角去认识高可用系统的建设。

参考文献BGP协议2021年Facebook死机事件Designing Data-Intensive Application

等省考公告现在有点考前焦虑怎么办？

你好，我是“一公考”一哥，很高兴围你解答这一问题。

首先的首先，请听一哥来自灵魂深处，直击肺腑的五个问题！

1、你确定公告一定会出么？

2、如果公告不出，你怎么办？

3、你确定公告之中有你能报考的岗位么？

4、如果没有合适的岗位你又怎么办？

5、你真的做好准备了么？？？

要解决你的焦虑，我们必须要解决以上这5个问题。

1、公告是否一定会出，这个应该是大概率事件。尽管因今年疫情影响，各地招考时间都有所推迟，但个别地市已发布招考公告。这就代表事情在按进度推进之中，靴子只是暂时悬着而已，总有掉下来的一天。因此，我们无需担心。

2、公告会不会不出呢？这一点“一哥”认为也很有可能。具体涉及到两个方面，一是你所在地区的疫情影响程度，例如湖北武汉等地区，势必会比其他地市延期更长的时间，现在已经接近年中，加之要为其他重磅级考试腾出人手和时间（例如高考、中考等），因此，临时性取消也是极有可能的。但是全国其他大部分省市地区应该只是延期招考而已。希望你根据所在地疫情影响程度进行预判，减少焦虑。

3、公告中是否有报考岗位。据“一哥”了解，根据考生所学专业及单位用人需求不同，每年的公考都会设定招考专业，经济、中文大类专业普遍招考人数居多，当然也有少部分不限专业的职位。除此之外，还涉及工作年限、政治面貌、年龄限制等等因素，所以每年公务员招考时，也有一部分考生因没有报考岗位而错过考试。希望你能根据报考单位往年招录人员情况，对岗位设置进行预判，减少焦虑。

4、那么如果真的没有合适的岗位呢？“一哥”建议你今早作出备选方案，例如寻找合适的就业机会，及时关注事业单位等其他招录考试情况，如果有机会可以多去试试。

5、你真的准备好了吗？一般来说，如果准备充分的考生，心里压力普遍要小的多。这类考生都抱着舍我其谁的必胜心态，考试的时间对他们来说也只是上班的迟早问题而已。在这里建议你还是要多做准备，打牢知识基础，利用未出公告的间隙查缺补漏，力争一举成功。

推荐你关注“一哥”的全平台自媒体“一公考”，每天定时更新，给你带来前所未有的详细解析，帮助你更好的补齐短板，一飞冲天！再次预祝你马到功成，一次上岸！

mysql新增字段为何会锁表？

MySQL在5.6.0版本之前对表结构进行修改会锁表的，5.6以后引入了online ddl，online ddl解决的就是修改表结构时候锁表的问题，能够让mysql在进行表变更时候，不影响正常的读写操作。要知道为什么表结构变更时候（新增／修改字段、索引的删除和添加）会锁表，就得知道当我们修改表结构时候，MySQL都做了哪些事情。SQL语言DQL：数据查询语言：SELECT <字段名表> FROM <表或视图名> WHERE <查询条件>;DML：数据操作语言：INSERT/UPDATE/DELETE;DDL：数据定义语言：CREATE TABLE/VIEW/INDEX;DCL：数据控制语言：授权、事物ROLLBACK/COMMIT;DDL在MySQL5.6之前的版本中，执行ddl有copy和inplace两种方式，可以根据命名就知道两种方式的意思。其中replace方式仅支持添加、删除索引操作。这两种方式都是锁表操作。copy方式执行的操作：创建一个临时表，和要修改的表结构一致；将原来的表锁住，禁止DML操作，可以DQL操作；将原来的表数据拷贝到临时表中将临时表重命名为原来的表，删除原来的表创建新的索引数据inplace方式执行的操作：新建索引的数据字典锁表，禁止DML操作，可以DQL操作；构造新的索引数据等待所有只读操作完毕创建索引结束所以表新增字段属于ddl数据定义语言，采用的是copy方式，锁表。那么是否说online ddl就不存在锁表的问题了呢？不是的，对于不支持online ddl操作的DDL语句，还得采取copy方式，比如修改列的数据类型、主键的删除、表字符集的修改等这些需要彻底修改记录数据格式的操作。线上大数据表如何执行DDL当我们需要对生产数据库中的表执行DDL的话，一定要小心，一定要慎之又慎。一不小心就会导致锁表，锁表一旦产生，数据库就会堆积大量对该表的请求，瞬间将数据库的连接吃没，CPU飙升，最后。。。数据库宕机！这里提供以下思路供大家参考：1.停服务执行，这种方式要求业务可以停止运行的情况下执行，比如半夜凌晨执行表结构变更，简单粗暴。

2.参考copy的方式自己执行这些步骤：

创建一个临时表table_copy，代表最新的表结构和索引；

把旧表的数据copy到新表：这步不要用sql操作，自己写一个脚本，按照数据的创建时间一次10000条的拷贝到新表，这个过程中可能会有新的数据进入，所以根据每一条记录的创建时间不断同步，直至两张表的记录完全一致，再执行第三步。删除旧表，把新表重命名为旧表的名字3.pt-online-schema-change：在线修改大数据表结构工具，可以google了解一下。