老生常谈,TCP三次握手、四次挥手过程及原理

本文来自于互联网,原始出处已无法考证 TCP 协议简述 TCP 提供面向有连接的通信传输,面向有连接是指在传送数据之前必须先建立连接,数据传送完成后要释放连接。 无论哪一方向另一方发送数据之前,都必须先在双方之间建立一条连接。在TCP/IP协议中,TCP协议提供可靠的连接服务,连接是通过三次握手进行初始化的。 同时由于TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议,TCP是全双工模式,所以需要四次挥手关闭连接。 TCP包首部 网络中传输的数据包由两部分组成:一部分是协议所要用到的首部,另一部分是上一层传过来的数据。首部的结构由协议的具体规范详细定义。在数据包的首部,明确标明了协议应该如何读取数据。反过来说,看到首部,也就能够了解该协议必要的信息以及所要处理的数据。包首部就像协议的脸。 所以我们在学习TCP协议之前,首先要知道TCP在网络传输中处于哪个位置,以及它的协议的规范,下面我们就看看TCP首部的网络传输起到的作用: 下面的图是TCP头部的规范定义,它定义了TCP协议如何读取和解析数据: TCP首部承载这TCP协议需要的各项信息,下面我们来分析一下:

Cache synchronization strategies

Introduction A system of record is the authoritative data source when information is scattered among various data providers. When we introduce a caching solution, we automatically duplicate our data. To avoid inconsistent reads and data integrity issues, it’s very important to synchronize the database and the cache (whenever a change occurs in the system). There… Continue reading Cache synchronization strategies

Cache-Aside pattern

Load data on demand into a cache from a data store. This can improve performance and also helps to maintain consistency between data held in the cache and data in the underlying data store. Context and problem Applications use a cache to improve repeated access to information held in a data store. However, it’s impractical… Continue reading Cache-Aside pattern

缓存和DB一致性问题

以下是从网络上摘取的一些缓存一致性方案,供参考。 产生原因 主要有两种情况,会导致缓存和 DB 的一致性问题: 并发的场景下,导致读取老的 DB 数据,更新到缓存中。 缓存和 DB 的操作,不在一个事务中,可能只有一个操作成功,而另一个操作失败,导致不一致。 当然,有一点我们要注意,缓存和 DB 的一致性,我们指的更多的是最终一致性。我们使用缓存只要是提高读操作的性能,真正在写操作的业务逻辑,还是以数据库为准。例如说,我们可能缓存用户钱包的余额在缓存中,在前端查询钱包余额时,读取缓存,在使用钱包余额时,读取数据库。 更新缓存的设计模式 1.Cache Aside Pattern(旁路缓存) 这是最常用最常用的pattern了。其具体逻辑如下: 失效:应用程序先从cache取数据,没有得到,则从数据库中取数据,成功后,放到缓存中。 命中:应用程序从cache中取数据,取到后返回。 更新:先把数据存到数据库中,成功后,再让缓存失效。 一个是查询操作,一个是更新操作的并发,首先,没有了删除cache数据的操作了,而是先更新了数据库中的数据,此时,缓存依然有效,所以,并发的查询操作拿的是没有更新的数据,但是,更新操作马上让缓存的失效了,后续的查询操作再把数据从数据库中拉出来。而不会像文章开头的那个逻辑产生的问题,后续的查询操作一直都在取老的数据。 要么通过2PC或是Paxos协议保证一致性,要么就是拼命的降低并发时脏数据的概率,而Facebook使用了这个降低概率的玩法,因为2PC太慢,而Paxos太复杂。当然,最好还是为缓存设置上过期时间。 2.Read/Write Through Pattern 在上面的Cache Aside套路中,我们的应用代码需要维护两个数据存储,一个是缓存(Cache),一个是数据库(Repository)。所以,应用程序比较啰嗦。而Read/Write Through套路是把更新数据库(Repository)的操作由缓存自己代理了,所以,对于应用层来说,就简单很多了。可以理解为,应用认为后端就是一个单一的存储,而存储自己维护自己的Cache。 Read Through Read Through 套路就是在查询操作中更新缓存,也就是说,当缓存失效的时候(过期或LRU换出),Cache Aside是由调用方负责把数据加载入缓存,而Read Through则用缓存服务自己来加载,从而对应用方是透明的。 Write Through Write Through 套路和Read Through相仿,不过是在更新数据时发生。当有数据更新的时候,如果没有命中缓存,直接更新数据库,然后返回。如果命中了缓存,则更新缓存,然后再由Cache自己更新数据库(这是一个同步操作) 下图自来Wikipedia的Cache词条。其中的Memory你可以理解为就是我们例子里的数据库。 3.Write Behind Caching Pattern Write Behind 又叫 Write Back。write back就是Linux文件系统的Page Cache的算法。… Continue reading 缓存和DB一致性问题

代理模式 (Proxy Pattern)-结构型模式第四篇

This is post 10 of 10 in the series “Design Patterns” 《设计模式》系列序——写给未来的自己 工厂方法模式(Factory Method)-创建型模式第一篇 抽象工厂模式(Abstract Factory Pattern)-创建型模式第二篇 单例模式(Singleton Pattern)-创建型模式第三篇 建造者模式(Builder Pattern)-创建型模式第四篇 原型模式(Prototype Pattern)-创建型模式第五篇 装饰者模式 (Decorator Pattern)-结构型模式第一篇 组合模式 (Composite Pattern)-结构型模式第二篇 适配器模式 (Adapter Pattern)-结构型模式第三篇 代理模式 (Proxy Pattern)-结构型模式第四篇 过去的大半年时间,日子过的忙忙碌碌!今天奉献一篇设计模式系列的新文章,挑选再三,始终觉得Proxy模式是很好的选择,Let’s Go! 定义: Proxy模式,简言之,它像一个代理人,或者说像一个包装盒,它用来封装、控制背后真实的对象,自己可以独立提供被外界访问的能力,它与背后真实的对象派生于相同的接口,但代理人通常会将对真实对象的调用更加简单化,以便外界更加容易的使用。在客户端看来,自己似乎是直接在操作被代理的真实对象,但事实是,所有的操作都经过代理人的封装、控制、包装,而这些额外的操作,对于客户端来说,似乎是透明的。 应用: Proxy模式,透明了对原始真实对象的调用,使我们有能力在调用真实对象的前后执行额外的动作,所以我们可以将一些与业务无关的软件基础功能添加在前后的额外动作中。比如Exception Handling, Logging, Caching等。 倘若再结合一些DI/IoC容器、编译器,有能力动态或静态地创建真实对象的代理,便无须手动去编写代理类,此时若配合一些编程语言的语法元数据(比如Java 中的@Attribute,C#中的[Attribute]),便可以在调用真实对象的方法前后执行额外的动作(通常可以称之为Interceptor 或Filter),这便初步实现了AOP编程。 UML:

适配器模式 (Adapter Pattern)-结构型模式第三篇

This is post 9 of 10 in the series “Design Patterns” 《设计模式》系列序——写给未来的自己 工厂方法模式(Factory Method)-创建型模式第一篇 抽象工厂模式(Abstract Factory Pattern)-创建型模式第二篇 单例模式(Singleton Pattern)-创建型模式第三篇 建造者模式(Builder Pattern)-创建型模式第四篇 原型模式(Prototype Pattern)-创建型模式第五篇 装饰者模式 (Decorator Pattern)-结构型模式第一篇 组合模式 (Composite Pattern)-结构型模式第二篇 适配器模式 (Adapter Pattern)-结构型模式第三篇 代理模式 (Proxy Pattern)-结构型模式第四篇 祖国母亲生病了,一场突如其来的新冠病毒让这个古老的中华民族正在经历一场全民参与、没有硝烟、却生离死别的战争。每每看到抖音里的那些感人场景虽然不至于声泪俱下,却也是感慨万千、悲愤不已。大家现在都蛰伏在家,等待时机成熟破茧化蝶。相信这个春节在很多人的记忆里永远再也无法抹去,只希望所有人都安好!岁岁平安! 想起抖音里某位才人拍摄的一段视频,视频里这位仁兄使用女用卫生巾夹在普通一次性口罩中混合使用,以提高过滤功效。感叹一句,此乃神人也,有才,不得不佩服!笑归笑,这里不禁想起了设计模式中一个称之谓适配器(Adapter)的模式,所谓Adapter模式简言之,适配器能够使原本两个不兼容的接口能够协同工作。这位才人他没有将卫生巾直接戴在嘴上、卡在脸上(那可不适配),而是通过一个一次性口罩进行了转换、隐藏、适配,然后交由一次性口罩来担负起对外的形象任务,抽象一点的说其实这也算是一个适配器模式的应用:) 好吧,让我们来正式认识一下Adapter模式吧!

组合模式 (Composite Pattern)-结构型模式第二篇

This is post 8 of 10 in the series “Design Patterns” 《设计模式》系列序——写给未来的自己 工厂方法模式(Factory Method)-创建型模式第一篇 抽象工厂模式(Abstract Factory Pattern)-创建型模式第二篇 单例模式(Singleton Pattern)-创建型模式第三篇 建造者模式(Builder Pattern)-创建型模式第四篇 原型模式(Prototype Pattern)-创建型模式第五篇 装饰者模式 (Decorator Pattern)-结构型模式第一篇 组合模式 (Composite Pattern)-结构型模式第二篇 适配器模式 (Adapter Pattern)-结构型模式第三篇 代理模式 (Proxy Pattern)-结构型模式第四篇 静悄悄中时间飞逝,感叹一句最近TMD真忙真累,好在天生坚强性格阳光,不吹不黑,下面开始讲结构型模式(Structural patterns)的第2篇,Composite Pattern,中文称之为组合或复合模式。 定义: Composite模式,能够灵活地实现循环、递归、部分-整体类的结构,使外部世界能够以一致的方式处理单体或集合。 解决的问题: 就像定义中所提及的那样,如何使客户端能够以一致的方式去访问某个单体或者集合,以使结构更加简洁 如何优雅的表达一个树形结构 怎么去解决(包含叶子Leaf的实现方式): 通过定义一个接口代表集合与个体所拥有的相同属性与行为,如IComponent 通过定义一个类Composite,它继承自IComponent,同时通过组合的方式它拥有一个名称为Components的属性,它代表着一个IComponent集合 Composite有能力将一个实现了IComponent接口的对象加入到Components中 对于Composite的任何请求,都会被重定向到属性Components中的每个个体分别去执行 通过定义一个类Leaf,它继承自IComponent,代表着不可再分割的个体 举个栗子,在一个树状结构中,树杆、树枝、树叉皆由Composite来表示,而Leaf代表的是末端的每片树叶。 怎么去解决(进一步抽象): 通过分析我们能够发现在上面的解决方式中,如果有能力分辨一个IComponent是树杆还是树叶,便可以将Composite和Leaf合并为一个类型,于是我们为IComponent引入一个新的属性HasChild,并且给它换一个更贴切的名字INode,如果HasChild为True,则代表它是Composite,反之则代表它是Leaf

装饰者模式 (Decorator Pattern)-结构型模式第一篇

This is post 7 of 10 in the series “Design Patterns” 《设计模式》系列序——写给未来的自己 工厂方法模式(Factory Method)-创建型模式第一篇 抽象工厂模式(Abstract Factory Pattern)-创建型模式第二篇 单例模式(Singleton Pattern)-创建型模式第三篇 建造者模式(Builder Pattern)-创建型模式第四篇 原型模式(Prototype Pattern)-创建型模式第五篇 装饰者模式 (Decorator Pattern)-结构型模式第一篇 组合模式 (Composite Pattern)-结构型模式第二篇 适配器模式 (Adapter Pattern)-结构型模式第三篇 代理模式 (Proxy Pattern)-结构型模式第四篇 本篇是结构型模式(Structural patterns)的第一篇,之所以选择Decorator模式第一个出场,是由于抓揪随机的结果。Decorator模式能够为行为带来灵活的组合,减少子类的数量,希望文章能够给大家带来一点帮助。 定义: Decorator模式,能够将行为动态地添加到一个类型实例,而不会影响其它的实例。 解决的问题: 如何在运行时给一个对象添加新的行为 如何减少子类的数量 我们知道通过新建一个子类,也能够为类型添加新的行为,但是它存在一个明显的缺陷:随着新行为数目的不断增加,需要增加更多数目的子类,并且行为之间无法组合使用 怎么去解决: 通过定义一个接口代表原始对象本身,如IComponent 通过定义一个接口IDecorator,它继承自IComponent,同时通过组合的方式它拥有IComponent 对于IDecorator的任何请求,都会被重定向到IComponent,并且在重定向前后我们有能力添加新的行为 UML:

原型模式(Prototype Pattern)-创建型模式第五篇

This is post 6 of 10 in the series “Design Patterns” 《设计模式》系列序——写给未来的自己 工厂方法模式(Factory Method)-创建型模式第一篇 抽象工厂模式(Abstract Factory Pattern)-创建型模式第二篇 单例模式(Singleton Pattern)-创建型模式第三篇 建造者模式(Builder Pattern)-创建型模式第四篇 原型模式(Prototype Pattern)-创建型模式第五篇 装饰者模式 (Decorator Pattern)-结构型模式第一篇 组合模式 (Composite Pattern)-结构型模式第二篇 适配器模式 (Adapter Pattern)-结构型模式第三篇 代理模式 (Proxy Pattern)-结构型模式第四篇 距离发布上篇软件设计模式文章《建造者模式》稍稍地已经过去两个多月,今天来谈一下第五个创建型模式,这也将是最后一个创建型模式——原型模式(Prototype Pattern)。 定义: Prototype模式,通过将对象自身进行复制来创建新的对象。多么简单的定义,该模式也很简单。 解决的问题: 在运行时如何动态创建一个对象的副本 怎么去解决: 通过定义一个含有Clone方法的Prototype接口 具体的实现类通过继承Prototype接口来创建自身的复制品 UML: