分布式系统一致性的分类

分布式系统一致性的分类在分布式系统中的CAP理论中有C(一致性),大郅表示分布式系统中节点状态或数据具有一致的特性 但一致性有着不同的分类,例如常见的用于取代CAP理论的BASE中的E,最终一致性,不同于强一致性,他强调着事务最终状态趋于一致,但中间态可能不一致,利用此篇文章总结一下分布式系统的一致性分类 根据实际系统的要求,分布式系统的一致性可以大致分为四类: 严格一致性 强一致性(线性一致/原子一致) 顺序一致性 弱一致性(最终一致性) 一个理想概念上的一致性,节点间数据完全一致,对外可表现为单个节点 由于网络延迟和通信等因素的存在,现实中这种一致性不可能存在 强一致性要求在全局时钟相同的条件下,对任何节点的读都相同且等于最后一次写成功的数据,这也就意味着仅仅在所有节点同步到数据后才会被标记为同步成功
分布式系统一致性的分类2021-03-13鱼鱼

JVM与GC

JVM与GCJMM,长下面这个样子: 其中,堆和栈区自然不做介绍了,主要介绍: 程序计数器:线程私有的,记录正在执行的字节码地址,换言之,它告诉我们某线程执行到了那里,分支、循环等也会依赖这个来执行,这一区域不会发生OOM问题 栈:就是正常所指的栈,每个方法被执行的时候都会同时创建一个栈帧(Stack Frame )用于存储局部变量表、操作栈、动态链接、方法出口等信息 每一个方法被调用直至执行完成的过程,就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程,这一区域会发生StackOverflow问题 堆:就是正常所指的堆,这里是GC的主要区域 方法区:线程私有的,是各个线程共享的内存区域,它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据,运行时常量池也包含在里面
JVM与GC2019-03-28鱼鱼

Redis高级特性:事务和pipelined以及在RedisTemplate中的应用

Redis高级特性:事务和pipelined以及在RedisTemplate中的应用Redis Pipelined是由Client提供的(是防止client端 阻塞的操作)一种请求redis的方式 Redis本身具有很高的吞吐量,因此性能最大的考察便是网络状况,如果应用到redis的网络状况不好,每次请求都将会出现轻微的 阻塞和延迟,这种延迟对于批量请求是很可怕的,譬如要进行数千次数据插入,或是批量获取数据时,我们就需要用到Pipelined Pipelined可以将多个请求无 阻塞的发出并按顺序将请求结果“打包”返回,这有点类似于并发请求,可以有效地利用等待结果的 阻塞时间 注意,Pipelined并不能保证原子性,即pipelined执行的内容可能会被其他客户端或是线程的指令"插队",若想要原子性操作,需要使用事务
Redis高级特性:事务和pipelined以及在RedisTemplate中的应用2020-06-21鱼鱼

Redis原理-源码解析:数据结构3 sorted set(zset))

Redis原理-源码解析:数据结构3 sorted set(zset))Redis的set数据结构在此不多讲,同Java中原理一样,set也可以理解为是hash剥离了value的数据结构,即同为dic 但是zset(有序集合)其实在底层原理上完全不同于set 所有原理实现基于Redis版本6.0.9 先看一下基本的指令实现,着重注意中文注解的地方 t_zset.c 可以看出zset的数据结构不是固定的,在其元素数或是元素的字符串过长时,其结构为zset;否则使用ziplist数据结构(像hash一样为了节省空间),二者的创建方法如下: ziplist的代码和原理可以参考我的博客Redis原理-源码解析:数据结构2 list-鱼鱼的Java小站,就是一个节省内存的压缩的链表结构
Redis原理-源码解析:数据结构3 sorted set(zset))2021-02-28鱼鱼

MYSQL的索引、引擎的实现原理和应用

MYSQL的索引、引擎的实现原理和应用本篇主要介绍数据库MySQL的索引实现原理,包括B+ Tree的原理,顺带提到了数据库的常用引擎 我们常见的数据库引擎就是InnoDB,还有另外一个常见一个引擎叫做MyISAM,这里着重介绍着两个引擎,执行show engines,可见MySQL所有的引擎如下: InnoDB采用行级锁,不会记录表中的数据个数,支持外键,高并发下使用事务的首选引擎,也是5.5之后MySQL的默认引擎(之前采用MyISAM),可以通过bin-log日志回滚数据,所以它比较适合处理数据量大的数据 PS:InnoDB最初不支持全文索引,在MySQL 5.6版本后添加了支持 MyISAM跟InnoDB截然相反,它采用表锁,记录了表的条目数,SELECT COUNT可以直接查看表中数据个数,支持FULLTEXT索引,不支持外键和事务,不能进行数据恢复操作,他比较适合频繁插入的数据,或是读操作远大于写操作时
MYSQL的索引、引擎的实现原理和应用2019-09-15鱼鱼

PyCharm与python快速开发

PyCharm与python快速开发Python语言作为“胶水语言”,简单易学,开发周期快,功能和扩展性强大,类库丰富 只依赖一门Java并不适用于所有情况,譬如快速开发一次性脚本(修复数据),通过使用Python效率更高,本篇文章旨在介绍本人快速入门Python的一些tips 注意,一些Python的基本语法在此不予介绍,推荐前往廖雪峰的博客查看,博客基于Python3.8版本 关于编译器等配置内容参考PyCharm帮助文档 从Python官网下载Python并安装,配置环境变量,安装PyCharm(这里 我们使用它作为IDE),这里略过 pip是python的包管理与安装工具,当你安装python后,pip也会随之被安装
PyCharm与python快速开发2021-01-16鱼鱼

浅谈锁机制、主流锁设计方案

浅谈锁机制、主流锁设计方案本文旨在探讨通用的锁机制实现逻辑,以Java中常见的锁实现为例 本文提到的锁,是指通过限制并发/并行访问所添加的安全措施,本质上是通过限制线程/进程同时更改数据或是读取数据与写入数据产生时序差从而造成数据问题 锁机制中,有一些常见特性: 可重入性 指同一线程/进程携带相同的标识可以反复多次加锁,每次加锁和释放锁对应的重入次数+1/-1; 读写锁/独享共享 是锁的不同运作模式,分为读写锁,读锁与写锁、写锁与写锁是互斥的,但多个线程/进程可以同时对一个逻辑添加读锁,独享共享是另一种叫法 公平性 锁分为 公平锁和非 公平锁, 公平锁指锁释放和获取的顺序严格按照索取的顺序,非 公平锁则是等待锁的对象共同进行锁释放机会的争抢
浅谈锁机制、主流锁设计方案2024-10-15鱼鱼

Spring MVC源码和设计思想序 综述

Spring MVC源码和设计思想序 综述Spring框架整体的流程:(图片引用请注明出处)
Spring MVC源码和设计思想序 综述2019-06-05鱼鱼

有关Session的碎碎念-ban掉cookie之后

有关Session的碎碎念-ban掉cookie之后java web中, 用session来表示用户浏览器(客户端)与服务器建立的一次会话 通常用sessionId来标记一个session,在Java中,有很简单的方式直接获取sessionId; 但是sessionId并不是session的特性,实际上,sessionId是在客户端首次创建会话时将生成的sessionId存入cookie中,在之后的访问中直接读取这个id值 当客户端禁止了cookie行为后,SessionId在每次刷新页面时都会更新,利用id来表示会话也成为了妄想,此篇文章意在说明,如何操作能使SessionId能够独立于cookie使用 这种操作其实在shiro中已经被应用了,当我们进入登录页面中,url后会出现";jssionid=xxxxxx",将sessionid显示的标注在url中,可以使用:
有关Session的碎碎念-ban掉cookie之后2019-03-08鱼鱼

Netty

NettyNIO相比IO有诸多利处,但平常开发中若是直接使用原生NIO进行业务开发是很不可取的,否则将面临臃肿而晦涩难懂的代码 所以日常开发中我们会时常使用封装了NIO操作代码的Netty来实现NIO操作 Netty是一个异步事件驱动的网络应用框架,用于快速开发可维护的高性能服务器和客户端
Netty2019-05-11鱼鱼

使用Shiro和token进行无状态登录

使用Shiro和token进行无状态登录我们之前可以使用shiro实现登录,但这些都是基于session或是cookie实现的,这些只能用于单机部署的服务,或是分布式服务共享会话,显然后者开销极大,所以JWT(JSON Web Token)应运而生,JWT是一套约定好的认证协议,通过请求携带令牌来访问那些需鉴权的接口 我们在这里使用token,原理类似,但是规则更为简单,没有形式上的约束,只是在请求Head或是body中添加token用于校验用户身份,token是可以和会话共存的,此处我们使用Shiro的会话登录结合JWT来实现无状态登录,从而实现扫码登录和一般的接口访问授权 项目中,需要实现无状态登录(单点登录,SSO),但是同时也要保持Shiro本身自带的会话登录
使用Shiro和token进行无状态登录2020-03-22鱼鱼

算法:动态规划解法及例题

算法:动态规划解法及例题经历过很多算法题,其中最常见的解题方法便是动态规划 动态规划(dynamic programming,即DP),是一种常见的求解最优解的方案,他通过将复杂的问题拆分为单阶段的小问题求解,核心思想是递推,通过简单基础的解一步步接近最优解 对于一个算法问题,总有一个相对令人满意的解,但却不一定是我们想要的最优解,譬如在解决动态规划中最经典的背包问题时,有些人首先想到简单省心的贪心算法,取价值最高或是性价比最高的物品组合,这种方案得到的很有可能是最优解,但贪心的算法并不适用于动态规划领域,若是物品中恰好有能将背包塞得很满的组合,而采用贪心策略却浪费了很多背包空间 其实贪心策略本身更多也是一种“相对最优”的解决方案,而很少是真正的最优,这一点请务必斟酌
算法:动态规划解法及例题2020-03-11鱼鱼
网站地图
1
首页 博客 {{screen}} 第 {{page}} 页
博客索引
{{blog.createDate}} ◔ {{blog.timeline}} 小头像 {{blog.author}} {{tag}}
{{blog.likeCount}}{{blog.commentCount}}
分类下暂时没有文章哦!
主题分类
{{taggroup.label}} 

{{tag.value}}