看，未来的博客

文章目录前言主从切换Redlock 红锁分布式系统专家马丁的质疑Redis 作者 Antirez 的反驳我的思考前言“分布式锁”这个话题在程序界有很大的关注量，引发了不少讨论。关于分布式锁有很多实现的方案，本文就讲基于 Redis 实现的分布式锁。一些基本的东西我就直接带过吧。问：为什么需要分布式锁？答：以前为什么需要互斥锁？Redis 分布式锁的演进：1、setnx存在问题：若上锁的实例还没解锁就挂了，就死锁了。解决方案：为锁设置一个过期时间。2、setnx px，为锁设置一个过期时.

文章目录时间为什么总是走“不准”？自动校准网络时间国际时间标准计算机如何同步时间？参考文献在网上看到这个问题，这是个好问题。在分布式锁的学习过程中看到马丁博士指出计算机时钟不可信的观点的时候，我也曾疑虑过，我认同这个观点，但是我不知道为什么计算机时钟不可信。今天有个大佬把这个问题解答了，我学习总结一下。时间为什么总是走“不准”？小时候，家里的墙上总是挂着一个大时钟。每过一段时间，我就要去手动调整一下，因为它不准了。那时候小，以为是指针向上走的时候比较难，向下走的时候有惯性，所以走着走着就有了偏差.

今天看到一篇写的很不错的文，想着自己总结一下。异地多活到底是什么？为什么需要异地多活？它到底解决了什么问题？究竟是怎么解决的？文章目录系统可用性单机架构主从复制不可抗力同城灾备同城双活两地三中心异地双活异地多活系统可用性让我们从最基础的开始往上垒。这个图我想会点开这篇博客的朋友应该都不陌生了，就不需要我多做解释了。我很喜欢的一句话和大家分享一下：很多模式是不能直接复制的。当数量级直线上升的时候，其背后的难度是几何增长的。图中小数点后的一个9，对系统的要求那绝对是更上一层楼了。难点一般体.

看到好的东西要记下来。首先，对于这个题目要满足：1、唯一性2、递增性（有利于数据库索引性能）3、高可用（要利于分库分表）4、无规律（安全）方案一：数据库自增实现要点：行锁优势：简单，利用数据库自有功能实现。绝对有序。缺点：有重复发号的风险，例如数据库主从切换的场景。需要特别保障其高可用。发号性能限制于数据库性能，如需提高发号能力，需要扩充数据库，成本高。方案二：Redis自增Redis 提供了自增的原子命令，可以保证唯一、有序。优点：简单，自有能力。高并发

文章目录幂等性方案一方案二幂等性幂等性：对于用户同一操作发起的一次或多次请求，不论请求多少次结果都应该是一致的，不会因为多次点击而产生副作用。解决潜在风险：没有事务、业务被迫中断等。对于接口设计如何才能做到幂等呢？方案一单次支付请求，也就是直接支付了，不需要额外的数据库操作了，这个时候发起异步请求创建一个唯一的ticketId，就是门票，这张门票只能使用一次就作废，具体步骤如下：异步请求获取门票调用支付，传入门票根据门票ID查询此次操作是否存在，如果存在则表示该操作已经执行过，直接返

文章目录一句话简介ratf算法分布式一致性的难点CAP理论分布式一致性：Raft算法选举过程新官上任根正苗红仍需努力一句话简介ratf算法没听过不要紧，我原先也没听过。Raft 算法是通过一切以领导者为准的方式，实现一系列值的共识和各节点日志的一致。熟悉吗？redis的哨兵用的就是这一套，不过哨兵简化了一些部分，提升了运行效率，降低了一致性，保证了最终一致性。晕吗？晕就完蛋了。分布式一致性的难点1、时钟不一致如果两条命令，分别为 A、B，被发往两个节点。由于网络延迟等原因，导致一个节点先.

愿打开此篇对你有所帮助。

最近接触到越来越多的实用主义，今晚逛陈硕大佬的知乎又看到那么一个话题讨论。先说一下我的观点，我保持中立哈哈哈哈哈哈。不是啥两边倒哈，我觉得应该具体问题具体分析，脱离了实际的辩论都是虾扯蛋。我说个故事吧，憋在我心里好久了。在我做第一个后端项目的时候，是老师给我们的框架，我又自己找学长拿了他的项目，两者框架差不多，看样子是没怎么改了。什么框架呢，很常见。说一下前置服务器，一个好好的前置服务器，拆分为：Inaddress模块、Sock模块Accept模块Epoll_base模块Epoll模块

from 《亿级流量网站架构核心技术 – 跟开涛学搭建高可用高并发系统》概述一个好的设计要做到，解决现有的需求和问题，把控实现和进度风险，预测和规划未来，不要过度设计，从迭代中演进和完善。在设计系统时，应多思考墨菲定律：1、任何事情都没有表面看起来那么简单。2、所有的事都会比你预计的时间长。3、可能出错的事总会出错。在系统划分时，也要思考康威定律：1、系统架构是公司组织架构的反映。2、应该按照业务闭环进行系统拆分/组织架构划分，实现闭环/高内聚/松耦合，减少沟通成本。3、如果沟.

愿打开此篇对你有所帮助。

愿打开此篇对你有所帮助。

文章目录背景游戏服务器架构要素游戏类型卡牌跑酷等休闲游戏弱交互游戏分区分服RPG游戏（RPG页游）数据共享游戏服务器房间游戏让我来学习一下。背景（专业，从背景出发）游戏服务器，是一个会长期运行程序，并且它还要服务于多个不定时，不定点的网络请求。所以这类服务的特点是要特别关注稳定性和性能。这类程序如果需要多个协作来提高承载能力，则还要关注部署和扩容的便利性；同时，还需要考虑如何实现某种程度容灾需求。由于多进程协同工作，也带来了开发的复杂度，这也是需要关注的问题。游戏服务器架构要素对于游戏服务端

愿打开此篇对你有所帮助。

昨晚和朋友讨论这个单例模式的加锁问题，因为我们是一个老师教出来的嘛，平时关系也好，在一个项目的一个细节上我们出了点不同意见。就是一个单例，到底要不要单例？为什么要或者为什么不要？单例模式是不是线程安全的？如果不安全，是整个对象锁住还是锁住哪些？他的想法是：要单例，因为是业务类，需要在多个地方使用到。单例不是线程安全的，整个对象锁住，老师教过，而且static对象创建的时候默认锁住。我的想法是：要单例，他说的就是我要说的。单例不是线程安全的，我试过不加锁的单例。不要把整个对象锁住。至于stati

试试？

这几天重新整理了一下设计模式模块儿，重写了一些，翻新了一些，删除了一些，还有一些没动的。所以时间线会有点乱。捋一下。我用过的设计模式（1）-- 本门心法我用过的设计模式（2）-- 单例模式我用过的设计模式（3）-- 观察者模式我用过的设计模式（4）-- 责任链模式我用过的设计模式（5）-- 中介者模式我用过的设计模式（6）-- 门面模式我用过的设计模式（7）–享元模式我用过的设计模式（8）-- 装饰者模式我用过的设计模式（9）-- 备忘录模式我用过的设计模式（10）-- 命令模式没.

桥接模式，号称设计模式中最抽象的一个，不是吹出来的啊。且看我能不能讲清楚啊。这时候就体现出小故事的重要性了，这也是我为什么每篇设计模式都要先讲个小故事，便于理解记忆嘛。文章目录...

文章目录前言架构图用例图流程图部署图类图时序图前言不想做架构师的程序员不是个好组长。昨天给学长看了我的“架构图”之后，才知道那个不是架构图，差不多一半用例图加一半的流程图吧，贻笑大方了。所以，知耻而后勇，太尴尬了。这一篇我不打算写多少的文字，一切尽在不言中，一图顶千言。架构图前段时间收集了一些架构图，学长也给了我一个示范：我找的示例：参考资料：软件架构概览参与阶段：需求分析阶段用例图用例图：用例图是指由参与者（Actor）、用例（Use Case），边界以及它们之间的.

练完FTP那个项目之后感觉我整个人都变了，以前我比较倾向于故事和代码实现，现在发现我只想看：模式定义、适用场景、优劣势，这些东西以前我都是一笔带过的。。。学设计模式，我觉得，知道干嘛用的，自然就能实现出来，要是代码写不出来那不应该来看设计模式，应该去看C++ Primer Plus哈哈哈。文章目录我们来作一棵文件管理树图：组合模式（安全模式）图：组合模式（透明模式）我们来作一棵文件管理树首先呢，我之所以一直不碰组合模式，是因为它真的庞大，比中介者模式还要庞大，因为它和树挂钩了。刚弄完FTP，那我.

文章目录命令模式命令模式咱也没读过什么书，看网上的命令模式讲的那叫个花里胡哨，看来看去，我接收到的讯息如下：命令请求者命令调用者命令储存命令回撤这是什么？这，我直接想到了消息队列好吧。还要我怎样？看一下命令模式的使用场景：当系统需要将请求调用者与请求接收者解耦时，命令模式使得调用者和接收者不直接交互。当系统需要随机请求命令或经常增加或删除命令时，命令模式比较方便实现这些功能。系统需要执行一组操作时，命令模式可以定义宏命令来实现该功能。当系统需要支持命令的撤销（Undo）操作和恢复.

文章目录如果能重来"时光隧道"代码实现应用场景如果能重来“如果能重来，我要选李白···”，“曾经有一份····”，“多渴望能够 找到一条时光隧道，重回到简单，容易觉得美好”，“我靠，我被Boss打死了，还好我有存档”····哈哈哈，如果时光能倒流，那该能圆了我们多少遗憾。如果能重来，我决不会在你最重要的那段时间离开，回头也已经于事无补了。在从程序设计中，有一个“美名昭著”的“重来”，对，就是栈。不过栈嘛，好用是固然的，但它和我们今天要讲的“备忘录模式”并不相冲，反而，还是相辅相成的呢。“时光隧.

文章目录装饰者模式实例：又是线程池回到装饰者模式装饰者模式动态的给一个对象添加一些额外的职责，就增加功能来说，装饰模式相比生成子类更加灵活。我一直没整明白这个模式到底是怎么玩的，是弄一个虚基类，然后去拓展它的很多子类吗？我以前一直是这么认为的。我现在依旧认为这是其中的一部分，但是后来，我又有了新的认知。新的认知来源于我去学Python的那段时间，我开了三个Python基础入门的班，在备课的过程中，接触到了Python的装饰器。当我看到这个名字的时候，第一反应就是装饰器模式，这，映射到C++当中.

文章目录开场白享元模式与池技术享元模式定义与结构线程池对象池类图对象池代码实现开场白之前写“桥接模式”的时候，说“桥接模式”是最抽象的设计模式，那是因为我没接触到“享元模式”。可能桥接模式是最抽象的设计模式，但是享元模式我觉得是最烦的设计模式了。因为这个模式和==“池技术”有着密不可分==的联系。享元模式与池技术说到享元模式，第一个想到的应该就是池技术了，String常量池、数据库连接池、缓冲池等等都是享元模式的应用，所以说享元模式是池技术的重要实现方式。面向对象技术可以很好地解决一些灵活性.

文章目录门面模式门面模式什么是“门面”？门面就是让你一看就知道里面可以提供什么东西，但是你又不会知道它是如何提供的。门面模式是什么？我知道，这张图也看不明白在讲什么。门面模式的定义已经呼之欲出了：要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。优点：高内聚，松耦合。安全，不通过门面上提供的方法，休想访问模块内部。说说我是如何在项目中使用这个模式的吧。这次带班的时候做了这么一张图：门面上的东西呢，是那些UI界面，而门后.

文章目录前言中介者模式缺点应用场景案例:大型相亲现场 VS 传统媒人模式中介者模式类图类图代码阐释前言什么是中介者模式呢？看上面那张图应该是一目了然了吧。我在做FTP本地云小项目的后端建设时用了中介者模式，将几个大块的职责分布到不同的服务器中去。我有写日报的好习惯，所以当时的事情是可以基本复现的。具体在这篇：FTP文件管理项目（本地云）项目日报（五），细节可查。中介者模式又叫调停者模式，但是我更喜欢中介者这个名字，因为一下就表达出这个设计的意图了。用一个中介对象封装一系列对象交互，中介.

文章目录前言责任链模式示例代码第一个epoll模块使用责任链模式优化过的epoll模块前言刚接触责任链的时候，我不是很喜欢这个模式，因为我不知道它能拿来干什么用啊。直到后来写那个FTP项目的时候，我用责任链+调停者优化了我的epoll模块之后，我爱死这个模式了！！！责任链模式什么是责任链模式呢？我们来看个小故事：最近给团队里的程序员们分了个等级，模仿着阿里的那套模式，将我们团队里人分为P6/P7/P8/P9/P10。来活儿的时候呢，就这样分配，根据难度初步估计，分配给对应的等级的程序员去做.

文章目录前言观察者模式观察者模式案例（线程池）观察者模式的优势注意事项前言关于设计模式，这次我要一改常态，我就挑重要的讲。那些碎碎的就算了。观察者模式说到观察者模式，那自然是离不开线程了。什么是观察者模式呢？顾名思义，是一种触发机制。在电视里见过埋手雷不？某个倒霉蛋不小心扯到了手雷的线，轰的一声儿手雷炸了，倒霉蛋瞬间连渣都没得了。这就是观察者模式，其中要素有：监视者、消息传递、响应者。那根线就是监视者，消息传递方式为线拉动了手雷的保险栓，响应者为手雷，轰的一声就是它的响应。观察者模式案例.

文章目录单一职责原则什么是“单一职责原则”？饱受争议的原则“单一职责原则”的优势怎么用？自己看着办里氏替换原则什么是“里氏替换原则”？关于里氏替换原则依赖倒置原则什么是“依赖倒置原则”关于依赖倒置原则的小故事依赖倒置，让项目并驾齐驱最佳实践接口隔离原则什么是“接口隔离原则”？接口要高内聚最佳实践迪米特法则松耦合的法则：迪米特法则开-闭原则何为“开闭原则”如何应对需求变化？单一职责原则什么是“单一职责原则”？如果要理解为：一个类只有一个职责，当然也是可以的，简单化嘛。单一职责的原话解释是这样的：Th.

文章目录单例模式代码实现提升部分多线程下的单例模式饿汉式单例懒汉还是饿汉？单例模式的优缺点单例模式什么是单例模式呢？在项目中，有些类是需要对它们进行“计划生育”的，即这个类只能有一个实例，如果出现多个实例则会有数据不一致的风险。单例模式：保证一个类仅有一个实例，并提供一个访问它的全局访问点。这个模式的类，叫单例类，所以类图我就不画了吧。单例模式的应用场景举例：牵扯到数据问题，数据库首当其冲，缓存自然也跑不了。代码实现//这里是.h文件//老板类单例class Single_Boss.