Redis原理-源码解析:数据结构3 hash

Redis原理-源码解析:数据结构3 hash 所有原理实现基于Redis版本6.0.9 hash在Redis中可以认为是套了一层的string,当然,对hash来说没有数字类型 让我们依旧通过基本命令看看hash的基本数据结构实现 在set方法中我们看到了hash的初始创建过程,一个hash最开始是zipist 想要了解ziplist可以看Redis原理-源码解析:数据结构2 list ,是为节省内存而生的链表格式 所以其实在使用ziplist时其查询的时间复杂度不是遵循hash的近似O(1),而是O(n),但是在数据量不大时,这种性能的损失微乎其微,并且能预见到大多数使用hash的场景都不会存储过多的字段 所以优先使用了更节省内存空间的ziplist
Redis原理-源码解析:数据结构3 hash 2020-11-29鱼鱼

ELK实战(Ⅰ) 基于ELK整合分布式业务日志

ELK实战(Ⅰ) 基于ELK整合分布式业务日志大多情况下,我们可能都习惯了使用linux指令查看日志,很多时候一句简简单单的tail、grep能定位绝大多数问题 但是面临复杂的目录结构和分布式系统产生的“分布式日志文件”,如果还要我们一个一个去查日志,就会耗费很多没必要的时间 可以利用ELK这套组件快速搭建一个日志系统 注意此文仅针对可能很多情况下格式不确定的业务日志,对于某些组件日志我们有更好的可视化实践方式,可以参考此系列的其他文章 对于一个日志系统,我们要确认我们的诉求,在不同的场景下采用不同的收集方式: 是否是分布式系统需要合并多个节点的日志 如果需要,则需要用分布式组件收集并合并日志,这也是一个日志系统最基本的要求;
ELK实战(Ⅰ) 基于ELK整合分布式业务日志2020-03-14鱼鱼

阿里巴巴Java开发手册 华山版 v1.5

阿里巴巴Java开发手册 华山版 v1.5《Java 开发手册》是阿里巴巴集团技术团队的集体智慧结晶和经验总结,经历了多次大规模一线实战的检验及不断完善,公开到业界后,众多社区开发者踊跃参与,共同打磨完善,系统化地整理成册 现代软件行业的高速发展对开发者的综合素质要求越来越高,因为不仅是编程知识点,其它维度的知识点也会影响到软件的最终交付质量 比如:数据库的表结构和索引设计缺陷可能带来软件上的架构缺陷或性能风险;工程结构混乱导致后续维护艰难;没有鉴权的漏洞代码易被黑客攻击等等 所以本手册以 Java 开发者为中心视角,划分为编程规约、异常日志、单元测试、安全规约、MySQL 数据库、工程结构、设计规约七个维度,再根据内容特征,细分成若干二级子目录
阿里巴巴Java开发手册 华山版 v1.52020-02-24鱼鱼

常见树形结构

常见树形结构树形结构 相关术语 结点(Node):表示树中的数据元素,由数据项和数据元素之间的关系组成 在图中,共有10个结点 结点的度(Degree of Node):结点所拥有的子树的个数,在图中,结点A的度为3 树的度(Degree of Tree):树中各结点度的最大值 在图中,树的度为3 叶子结点(Leaf Node):度为0的结点,也叫终端结点 在图中,结点E、F、G、H、I、J都是叶子结点 分支结点(Branch Node):度不为0的结点,也叫非终端结点或内部结点 在图中,结点A、B、C、D是分支结点 孩子(Child):结点子树的根 在图中,结点B、C、D是结点A的孩子
常见树形结构2019-03-15鱼鱼

分布式系统中的CAP原则与BASE原则

分布式系统中的CAP原则与BASE原则没有十全十美的分布式系统,分布式的痛点就在于各个节点状态的统一,CAP和BASE便是描述它的状态 本文中的分布式系统不仅指一套全是无状态的应用的服务系统,单纯依靠共享资源(如多个无状态的服务共用数据库或NoSQL而不在内存或是本身的服务容器中存储任何数据)运转的服务不是纯粹的分布式系统,分布式系统中一般需要包含有状态的服务(如主从同步的Mysql、多机哨兵模式的Redis、设置会话共享的分布式Tomcat服务) 图A 分布式架构雏形 ( 试想在上图中,若是网关通过A分区对数据做出了修改,此时还没有写入数据库但是A分区的缓存做出了调整,在分区容错的情况下A不能直接与B通信,那A与B分区就会失去一致性
分布式系统中的CAP原则与BASE原则2019-09-29鱼鱼

Spring源码解析(1) 基于SSM看Spring的使用和Spring启动监听

Spring源码解析(1) 基于SSM看Spring的使用和Spring启动监听查看源码的顺序就见仁见智了,比较普遍的做法是从IoC入手,了解容器注入的每一个环节,掌握大致的流程 由于使用的是Spring,所以在这里我们引入比较古老的xml配置文件进行bean的配置,首先定义一个bean: 配置描述bean的xml,核心只有一行: 这样一来就可以使用BeanFactory这个容器来注入bean并使用了: 本来有封装好的XmlBeanFactory,这一类现在已经被弃用了,所以采用了他的父类DefaultListableBeanFactory;当然,也可以使用更加方便和常用的ApplicationContext: 当然从xml文件读取bean的配置只是其中一种目前用的不多的加载方式,还有基于包扫描等加载bean的方法,此处仅为理解IoC的基本使用
Spring源码解析(1) 基于SSM看Spring的使用和Spring启动监听2020-08-04鱼鱼

什么是web服务器?什么是web应用服务器?容器、以及服务器概念的区分(萌新向)

什么是web服务器?什么是web应用服务器?容器、以及服务器概念的区分(萌新向)本文主要是为了帮助萌新理解在web开发时遇到的关于web工作原理的疑问,由于本人水平十分有限,所以本文仅作为一般性参考,如有错误,欢迎批评指正OVO 首先说明的是,我们所谓的web服务器并不是物理上的服务器,而是建立在物理服务器上的一个web应用的运行环境,是一个软件服务器 这就好比前后端分离开发时,后端模块在物理服务器上的JVM,前端也需要一个“运行环境”进行工作,那么web服务器端概念就应运而生了,大概就好比下图 上图中拥有VUE经典的原谅色的web服务器就是我们前端运行的地方,可见web服务器的主要作用是给前端一个合理的运行环境,其实不只是看起来那么简单,web服务器还要处理代理、反向代理、跨域、并支持并发等等
什么是web服务器?什么是web应用服务器?容器、以及服务器概念的区分(萌新向)2019-06-16Agostino

IO多路复用模型:select、poll、epoll对比

IO多路复用模型:select、poll、epoll对比我们平时提到的I/O几乎都是同步 阻塞模型,譬如网络请求的socket IO,在数据返回前,相应的线程或是进程将会一直 阻塞直到数据返回,比较直接的处理便是针对IO流一对一的监听,但在IO返回前,相应的系统资源会平白无故的浪费,这种处理方式会大大降低服务器的吞吐 如果我们用很少的线程来监听这些IO,就能实现对系统资源的更好利用,在相应的socket有数据返回时才去读取数据 这种方式被称作IO多路复用,在Linux系统中,实现IO多路复用的方式(从古老到新)有select、poll和epoll 现在很多中间件都使用epoll IO多路复用模型才因此有着很高的性能和吞吐 此处简单描述三种方式的实现和区别
IO多路复用模型:select、poll、epoll对比2020-08-11鱼鱼

IO与NIO

IO与NIO我们都知道IO流传输,其实IO模型有很多,例如BIO、NIO、AIO等,传统的IO都是同步的 IO为各种流操作 IO操作分类 I IO操作分类 II 其中,输入流可以为InputStream和Reader,分别为字节流和字符流,对应地,输出流为OutputStream和Writer,具体的使用在此不详述 NIO是IO模型中后推出的新IO模型 NIO并不一定是多线程的,但是NIO是多管道的,利用缓冲作为中间介质进行数据传输,运用的其实是多路复用技术,它恰恰是通过减少线程数量从而减少上下文的频繁切换,提高性能 Channel:通道,相当于一个连接,不能直接输出数据,只能与Buffer交换数据
IO与NIO2019-05-11鱼鱼

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

算法:动态规划解法及例题经历过很多算法题,其中最常见的解题方法便是动态规划 动态规划(dynamic programming,即DP),是一种常见的求解最优解的方案,他通过将复杂的问题拆分为单阶段的小问题求解,核心思想是递推,通过简单基础的解一步步接近最优解 对于一个算法问题,总有一个相对令人满意的解,但却不一定是我们想要的最优解,譬如在解决动态规划中最经典的背包问题时,有些人首先想到简单省心的贪心算法,取价值最高或是性价比最高的物品组合,这种方案得到的很有可能是最优解,但贪心的算法并不适用于动态规划领域,若是物品中恰好有能将背包塞得很满的组合,而采用贪心策略却浪费了很多背包空间 其实贪心策略本身更多也是一种“相对最优”的解决方案,而很少是真正的最优,这一点请务必斟酌
算法:动态规划解法及例题2020-03-11鱼鱼

网络时延、异步IO、Pipeline

网络时延、异步IO、Pipeline通过使用多线程是能提高网络延迟带来的负面效应的,也就是在IO密集型的应用中(尤其是网络IO密集应用中),通过异步操作或能显著提高性能,本篇讨论相关问题 并不是异步(多线程)定能提高性能,有这种讨论也是发现经常有人会滥用多线程 通常会有一种说法:如果想要采用多线程的来执行一段任务,为了提高性能,假设服务器中有N个核心,推荐在CPU密集型的应用中启用N个线程,而在IO密集型的任务中启用2*N个线程 本人不是很认同此种说法,他只能代表一个大致的度量,在实际应用中几乎可以说完全不准确,一般来说,权衡系统资源与性能后,前者可能需要更少的线程数,而后者根据实际情况也许适宜分配更多的线程数 这个概念大家一般都不是很陌生,在此再次科普下:所谓IO密集型任务,即是任务的资源消耗多集中在系统IO上,这里的IO本来包括磁盘IO和网络IO等,但是磁盘IO涉及文件句柄操作等系统限制不在本篇讨论,所以此篇文章所提主要指网络IO,高网络IO也是绝大多数web应用的特性
网络时延、异步IO、Pipeline2021-04-21鱼鱼

DDD领域下的架构模式——CQRS架构

DDD领域下的架构模式——CQRS架构//TODO
DDD领域下的架构模式——CQRS架构2021-06-24鱼鱼
网站地图
1
首页 博客 {{screen}} 第 {{page}} 页
博客索引
{{blog.createDate}} ◔ {{blog.timeline}} 小头像 {{blog.author}} {{tag}}
{{blog.likeCount}}{{blog.commentCount}}
分类下暂时没有文章哦!
主题分类
{{taggroup.label}} 

{{tag.value}}