Browsed by
月份:2020年8月

HAProxy Nginx LVS Apache总结篇

HAProxy Nginx LVS Apache总结篇

閱讀本文約花費: 8 (分鐘)一、今天花点时间总结分享一下HAProxy、Nginx、LVS、Apache: 比较 HAProxy Nginx LVS Apache   简介 高可用、负载均衡且基于TCP和HTTP应用的代理,支持高并发,多集群反代。 高性能http和反向代理服务器、邮件代理服务器,支持高并发,轻量级Web,低系统资源消耗。 Linux虚拟服务器,常用VS/NAT、VS/TUN和VS/DR,三种模式负载均衡。 高性能Web服务器,支持代理,市场份额很高。   优点缺点 1、抗负载能力强,负载均衡速度高。2、支持session保持,Cookie引导,可通过url检测后端服务器健康状态。3、也可做MySQL、Email等负载均衡。4、一般不做Web服务器的Cache。 1、抗负载能力强。2、http、https、Emai协议功能较好,处理相应请求快。3、Web能力强,配置简单,支持缓存功能、适用动静分离,低内存消耗。4、不支持session直接保持,但可通过ip_hash解决,通过端口对后端服务器健康检查。 1、抗负载能力强。2、通过vrrp转发(仅分发)效率高,流量通过内核处理,没有流量产生。(理论)3、相当稳定可靠。4、不支持正则,不能做动静分离,配置略复杂,需要IP略多。 1、Web处理能力强,市场份额很高。(不过后期Ngi…

Read More Read More

Nginx 限流配置

Nginx 限流配置

閱讀本文約花費: 12 (分鐘)限流算法 令牌桶算法 算法思想是: 令牌以固定速率产生,并缓存到令牌桶中; 令牌桶放满时,多余的令牌被丢弃; 请求要消耗等比例的令牌才能被处理; 令牌不够时,请求被缓存。 漏桶算法 算法思想是: 水(请求)从上方倒入水桶,从水桶下方流出(被处理); 来不及流出的水存在水桶中(缓冲),以固定速率流出; 水桶满后水溢出(丢弃)。 这个算法的核心是:缓存请求、匀速处理、多余的请求直接丢弃。相比漏桶算法,令牌桶算法不同之处在于它不但有一只“桶”,还有个队列,这个桶是用来存放令牌的,队列才是用来存放请求的。 从作用上来说,漏桶和令牌桶算法最明显的区别就是是否允许突发流量(burst)的处理,漏桶算法能够强行限制数据的实时传输(处理)速率,对突发流量不做额外处理;而令牌桶算法能够在限制数据的平均传输速率的同时允许某种程度的突发传输。 Nginx按请求速率限速模块使用的是漏桶算法,即能够强行保证请求的实时处理速度不会超过设置的阈值。 Nginx官方版本限制IP的连接和并发分别有两个模块: limit_req_zone 用来限制单位时间内的请求数,即速率限制,采用的漏桶算法 “leaky bucket”。 limit_req_conn 用来限制同一时间连接数,即并发限制。 limit_req_zone 参数配置 limit…

Read More Read More

并发之Striped64(累加器)和 LongAdder

并发之Striped64(累加器)和 LongAdder

閱讀本文約花費: 10 (分鐘)并发之Striped64(累加器) Striped64是在java8中添加用来支持累加器的并发组件,它可以在并发环境下使用来做某种计数,Striped64的设计思路是在竞争激烈的时候尽量分散竞争,在实现上,Striped64维护了一个base Count和一个Cell数组,计数线程会首先试图更新base变量,如果成功则退出计数,否则会认为当前竞争是很激烈的,那么就会通过Cell数组来分散计数,Striped64根据线程来计算哈希,然后将不同的线程分散到不同的Cell数组的index上,然后这个线程的计数内容就会保存在该Cell的位置上面,基于这种设计,最后的总计数需要结合base以及散落在Cell数组中的计数内容。这种设计思路类似于java7的ConcurrentHashMap实现,也就是所谓的分段锁算法,ConcurrentHashMap会将记录根据key的hashCode来分散到不同的segment上,线程想要操作某个记录只需要锁住这个记录对应着的segment就可以了,而其他segment并不会被锁住,其他线程任然可以去操作其他的segment,这样就显著提高了并发度,虽然如此,java8中的ConcurrentHashMap实现已经抛弃了java7中分段锁的设计,而采用更为轻量级的CAS来协调并发,效率更佳。原理如下图所示: JavaCopy…

Read More Read More

Windows 95系统问世25周年 这10个功能到现在都在用

Windows 95系统问世25周年 这10个功能到现在都在用

閱讀本文約花費: 2 (分鐘)8月24日是Windows 95系统问世25周年的纪念日,1995年的当天这个划时代的OS系统开卖,它带来的影响极为深远,很多技术或者习惯大家直到今天都在用。在Win 95那个年代,电脑远远算不上普及,而且当时很多人还在用DOS系统,Win95带来的图形化界面绝对让人耳目一新。 此外,Win95还带来很多软件或者体验的第一次,比如32位系统,IE浏览器等等,这些开创性的东西不仅在当时很新鲜,实际上我们现在用的Win系统依然保留了当时的习惯。 外媒日前汇总了Win95系统直到今天都在用的10大创新/技术了: ·桌面 ·开始菜单 ·任务栏 ·长文件名 ·即插即用 ·用户文件 ·USB ·文件浏览器 ·IE浏览器 ·回收站 这10个习惯或者说创新确实影响深远,其中一些开创性的东西现在已经离不开了,比如USB接口、即插即用、回收站,哪怕部分技术其实并不是微软首创,但Win95的整合依然推动了技术革命。 当然,放到2020年来看的,上面10大创新中IE浏览器恐怕是没啥底气了,传统意义上的IE已经被放弃了,很快微软自己都不支持IE浏览器了,早点放弃也好。 No tags for this post.

【高危安全通告】Jackson-databind远程代码执行漏洞

【高危安全通告】Jackson-databind远程代码执行漏洞

閱讀本文約花費: 1 (分鐘)一、背景信息 近日,安全狗关注到jackson-databind官方发布最新版本,当中修复了一处反序列化远程代码执行漏洞(CVE-2020-24616),漏洞存在于br.com.anteros:Anteros-DBCP库类中,攻击者可以通过精心构造的请求包在受影响的 Jackson 服务器上进行远程代码执行。 安全狗提醒使用jackson-databind的用户及时安排自检并做好安全加固。 安全通告信息 漏洞名称 Jackson-databind远程代码执行漏洞 漏洞影响版本 jackson-databind < 2.9.10.6  漏洞危害等级 高危 厂商是否已发布漏洞补丁 是 版本更新地址 https://github.com/FasterXML/jackson-databind/release 安全狗总预警期数 136 安全狗发布预警日期 2020年8月26日 安全狗更新预警日期 2020年8月26日 发布者 安全狗海青实验室 处置措施 安全建议 目前官方已在最新版本中修复了该漏洞,请受影响的用户升级至安全版本。 下载地址如下: https://github.com/FasterXML/jackson-databind/releases/tag/jackson-databind-2.9.10.6 Tags: Git

Java 常见的几种 OOM

Java 常见的几种 OOM

閱讀本文約花費: 6 (分鐘)1、StackOverflowError(栈空间溢出) public class StackOverflowErrorDemo { public static void main(String[] args) { main(args); // Exception in thread “main” java.lang.StackOverflowError }} 上面这种 OOM 比较好理解,在 main 方法中循环调用 main 方法,循环产生的大量形参都会在栈空间进行创建,当超过栈空间的大小,就会导致栈空间溢出,发生 OOM。 2、Java Heap Space(堆空间溢出) public class JavaHeapSpaceDemo { public static void main(String[] args) { // 我配置了虚拟机参数 -Xms10m -Xmx10m 初始化堆内存和最大堆内存都是 10m byte[] b = new byte[20 * 1024 * 1024]; // 这里 new 了 20m 的字节数组 // Exception in thread “main” java.lang.OutOfMemoryError: Java heap space }} 上面的这个 OOM 也比较好理解,我给 JVM 设置的初始化堆内存…

Read More Read More

如何对 ElasticSearch 集群进行压力测试

如何对 ElasticSearch 集群进行压力测试

閱讀本文約花費: 14 (分鐘)当 ElasticSearch 的业务量足够大,比如每天都会产生数百 GB 数据的时候,你就会自然而然的需要一个性能更强的 ElasticSearch 集群。特别是当你使用的场景是一些典型的大量数据进入的场景,比如网站日志、用户行为记录、大型电商网站的站内搜索时,一个强劲的 ElasticSearch 是必不可少的组件。在这样的场景下,如何找到一组合适的 ElasticSearch 集群?如何评估 ElasticSearch 集群的性能,就成为了一个十分重要的因素。 用什么 ElasticSearch 进行压力测试? 对于 ElasticSearch 性能测试和压力测试方面,其实有很多不同的方案,比如: Rally:Rally 是 Elastic 官方针对于 ElasticSearch 的宏观测试工具。 ESPerf:一个基于 Golang 编写的 ElasticSerch 性能测试工具 Elasticsearch Stress Test:由著名的 ElasticSearch 服务提供商 Logzio 开发的性能测试工具 除了这些定制化的工具意外以外,ElasticSearch 也可以借由其 Restful API 来使用Load Runner、JMeter等老牌工具进行测试,这些工具零零散散,各有各的用法和用途,不过,对于广大开发者而言,还是官方出…

Read More Read More

十五张图带你彻底搞懂从 URL 到页面展示发生的故事

十五张图带你彻底搞懂从 URL 到页面展示发生的故事

閱讀本文約花費: 2 (分鐘) 某一天小林去面试,面试官说问你一道经典面试题吧,从“输入一个URL到页面展示中间发生了什么?”,小林一听激动了,心里暗自高兴说这道题我背过呀,然后哗啦哗啦开启了背书模式。背完之后面试官不是很满意,思路并不是很清晰呀!!!(纯属个人杜撰的小故事,切勿当真。) 下面就让我们来唠一唠这个小问题,有不准确的地方还望各位大佬指正。对于这个问题将从浏览器包含的进程着手,然后用用一张图来展示整体流程,最后分别从导航阶段和*渲染阶段*两个方面详细阐述从输入一个URL到页面展示中间发生的过程。 一、浏览器进程 在聊上述话题之前要意识到目前浏览器处在多进程时代,包含浏览器进程、渲染进程、GPU进程、网络进程、插件进程 二、整体流程 用一张图来表示整个流程,整个流程包含导航阶段和*渲染阶段*两大部分,其中每个具体细节所需要的进程如下图所示。 三、导航阶段 导航阶段主要包含用户输入、URL请求、准备渲染进程、提交文档四个部分 3.1 用户输入 3.2 URL请求过程 3.3 准备渲染进程 3.4 提交文档 四、渲染阶段 当文档数据传输完成后将进入渲染阶段,渲染阶段主要包含构建DOM树、样式计算、布局阶段、分层、图层绘制、分块、栅格化操作、合成和显示。其整个渲染阶段流程如下图所示。 4.1 构建DOM树 4.2 样式计算 4.3 布局阶段 4.4 分层 4.5 图层绘制 4….

Read More Read More

Linux下如何高效切换目录?

Linux下如何高效切换目录?

閱讀本文約花費: 6 (分鐘)Linux 下对于目录的切换,大家肯定会想到一个命令:cd 命令。这个是 Linux 下再基本不过的命令,如果这个命令都不知道的话,赶紧剖腹自尽去吧。 cd 命令确实很方便,但如果需要频繁在下面的目录切换,你可能要怀疑人生了: 如果只会 cd 命令的话,那么就需要不停地 cd ,直到你发疯。 在这种情况下,我们如何高效进行目录切换呢?良许给大家介绍三个命令:pushd 、 popd 、 dirs 。 这三个命令其实都是对 目录栈 进行操作,而 目录栈 就是一个保存目录的栈结构,该栈结构的顶端永远都存放着当前目录(敲黑板了,重点!!)。 有编程基础的同学都知道,栈 都是遵循着 后进先出 的原则。也就是说,在栈结构里,后面进栈的元素,将先出栈。 复习完基本概念,我们再来详细这三个命令。 显示目录栈内容:dirs 首先是 dirs 。这个命令很简单,就是显示目录栈的内容。它有以下三个常用选项: 选项 含义 -p 每行显示一条记录 -v 每行显示一条记录,同时展示该记录在栈中的index -c 清空目录栈 其中,-p 与 -v 选项的区别是,-v 选项将显示每条记录在栈中的…

Read More Read More

消息疯狂堆积!RocketMQ 出 Bug 了?

消息疯狂堆积!RocketMQ 出 Bug 了?

閱讀本文約花費: 21 (分鐘)前言 用过 MQ 的同学,可能会遇到过消息堆积的问题。而肥壕最近也踩上了这个坑,但是发现结果竟然是这么一个意料之外的原因而导致的。 正文 那一晚月黑风高,肥壕正准备踏上回家的路,突然收到告警短信轰炸!“MQ 消息堆积告警 [TOPIC: XXX] ” 肥壕心里“万只草泥马崩腾~” 第一反应是:“怎么肥事?刚下班就来搞事情???” 于是乎赶回公司赶紧打开电脑,登上 RocketMQ 后台查看(公司自己搭建的开源版RocketMQ) 握草 (キ`゚Д゚´)!!! 竟然堆积了3亿多条消息了??? 要知道出现消息堆积无在乎这个问题: 生产者的生产速度 >> 消费者的处理速度  1. 生产者的生产速度骤增,比如生产者的流量突然骤增 2. 消费速度变慢,比如消费者实例 IO 阻塞严重或者宕机 擦了一下头上的冷汗😓…赶紧登上消费者服务器瞧瞧。 应用运行正常!服务器磁盘IO 正常!网络正常! 再去上去生产者的服务器,咦…流量也很正常! 什么???佛了😨 …生产者和消费者的应用都很正常,但是为什么消息会堆积怎么多呢?看着这堆积的数量越堆越多(要是这是我头发的数量那该多好啊),越发着急。 虽然说 RocketMQ 版能支持 10 亿级别的消息堆积,不会因为消息堆积导致性能明显下降,&#x1…

Read More Read More

数据库的乐观锁和悲观锁并非真实的锁

数据库的乐观锁和悲观锁并非真实的锁

閱讀本文約花費: 10 (分鐘)开局 我们平时编写程序的时候,有很多情况下需要考虑线程安全问题,一个全局的变量如果有可能会被多个同时执行的线程去修改,那么对于这个变量的修改就需要有一种机制去保证值的正确性和一致性,这种机制普遍的做法就是加锁。其实也很好理解,和现实中一样,多个人同时修改一个东西,必须有一种机制来把多个人进行排队。计算机的世界中也是如此,多个线程乃至多个进程同时修改一个变量,必须要对这些线程或者进程进行排队。数据库的世界亦是如此,多个请求同时修改同一条数据记录,数据库必须需要一种机制去把多个请求来顺序化,或者理解为同一条数据记录同一时间只能被一个请求修改。 锁是数据库中最为重要的机制之一,无论平时写的select语句,还是update语句其实在数据库层面都和锁息息相关。如果没有锁机制,操作数据的时候可能会发生以下情况: 更新丢失:多个用户同时对一个数据资源进行更新,必定会产生被覆盖的数据,造成数据读写异常。 不可重复读:如果一个用户在一个事务中多次读取一条数据,而另外一个用户则同时更新啦这条数据,造成第一个用户多次读取数据不一致。 脏读:第一个事务读取第二个事务正在更新的数据表,如果第二个事务还没有更新完成,那么第一个事务读取的数据将是一半为更新过的,一半还没更新过的数据,这样的数据毫无意义。 幻读:第一个事务读取一个结果集后,第二个事务,对这个结果集经行增删操作,然…

Read More Read More

分布式定时任务调度框架实践

分布式定时任务调度框架实践

閱讀本文約花費: 14 (分鐘)分布式任务调度框架几乎是每个大型应用必备的工具,本文介绍了任务调度框架使用的需求背景和痛点,对业界普遍使用的开源分布式任务调度框架的使用进行了探究实践,并分析了这几种框架的优劣势和对自身业务的思考。 一、业务背景 1.1 为什么需要使用定时任务调度 (1)时间驱动处理场景:整点发送优惠券,每天更新收益,每天刷新标签数据和人群数据。 (2)批量处理数据:按月批量统计报表数据,批量更新短信状态,实时性要求不高。 (3)异步执行解耦:活动状态刷新,异步执行离线查询,与内部逻辑解耦。 1.2 使用需求和痛点 (1)任务执行监控告警能力。 (2)任务可灵活动态配置,无需重启。 (3)业务透明,低耦合,配置精简,开发方便。 (4)易测试。 (5)高可用,无单点故障。 (6)任务不可重复执行,防止逻辑异常。 (7)大任务的分发并行处理能力。 二、开源框架实践与探索  2.1 Java 原生 Timer 和ScheduledExecutorService 2.1.1 Timer使用 Timer缺陷: Timer底层是使用单线程来处理多个Timer任务,这意味着所有任务实际上都是串行执行,前一个任务的延迟会影响到之后的任务的执行。 由于单线程的缘故,一旦某个定时任务在运行时,产生未处理的异常,那么不仅当前这个线程会停止,所有的定时任务都会停止。 Timer任…

Read More Read More

上 Kubernetes 到底有什么业务价值?

上 Kubernetes 到底有什么业务价值?

閱讀本文約花費: 13 (分鐘)开篇,我们先思考这样一个问题:“为什么要基于 Kubernetes 去构建一个应用管理平台?” 上图是一个本质的问题,我们在落地 K8s 经常遇到的一个问题。尤其是我们的业务方会问到这么一个问题,我们上 Kubernetes 有什么业务价值?这时候作为我们 K8s 工程师往往是很难回答的。原因在哪里呢?实际上这跟 K8s 的定位是相关的。K8s 这个项目呢,如果去做一个分析的话,我们会发现 K8s 不是一个 PaaS 或者应用管理的平台。实际上它是一个标准化的能力接入层。什么是能力接入层呢?大家可以看一下下图。 实际上通过 Kubernetes 对用户暴露出来的是一组声明式 API,这些声明式 API 无论是 Pod 还是 Service 都是对底层基础设施的一个抽象。比如 Pod 是对一组容器的抽象,而 Deployment 是对一组 pod 的抽象。而 Service 作为 Pod 的访问入口,实际上是对集群基础设施:网络、网关、iptables 的一个抽象。Node 是对宿主机的抽象。Kubernetes 还提供了我们叫做 CRD(也就是 Custom Resource)的自定义对象。让你自己能够自定义底层基础设施的一个抽象。 而这些抽象本身或者是 API 本身,是通过另外一个模式叫做控制器 (Controller) 去实现的。通过控制器去驱动…

Read More Read More

学了那么多技术,为何依然成不了架构师

学了那么多技术,为何依然成不了架构师

閱讀本文約花費: 13 (分鐘)在我们的周围存在着很多的全栈工程师,极客达人,他们热爱技术,善于使用各种工具,甚至可以熟练使用多种开发语言,解决各种技术上的问题,但是却无法成为掌控全局的架构师,无法做出最优的架构决策,这是为什么呢? 架构中的哲学 在《道德经》中提到四个字,叫“道、法、术、器”。“道”是天道,“法”是人定的,就是说你该怎么跟着“天道”去做。“法”也有善恶之分。顺应天道的“法”就是善法,相反,违背天道的“法”就是恶法。“术”是指技术层面上的操作方法。“器”是指有型的物质或是有形的工具。 无独有偶,在学习阳明心学的时候,其核心教义也和道家思想一脉相承。 无善无恶是自然之道,有善有恶是人性之法,知善知恶需判别之术,为善去恶用合法之器。他们不是含义上的等价,却是哲学思想层次的完美统一。从道出发,以法为界,以道御术,善于用器。这是一个循序渐进的过程,是解决问题的步骤和方法论。 对于大部分程序员来说,不论是我们参与的工作,还是接受的培训,基本都属于“器”、“术”的范畴。而架构师具备能力:理解业务,全局把控(道),选择合适技术(法),解决关键问题(术),指导研发落地实施(器)。可见成为一名合格的架构师,不仅仅只是具备技术能力就可以完全胜任的,还需要领悟架构之道,架构之法并合理的应用。 何为架构的道、法、术、器呢? 道:架构设计的方向,大道至简。 法:架构设计的原则,有据可依。 术…

Read More Read More

云计算术语(中英文对照)

云计算术语(中英文对照)

閱讀本文約花費: 7 (分鐘)以下搜集了一些在云计算中会比较常遇到的一些术语,提供中英对照信息: 1. 自由计算      free computing  2. 弹性可伸缩    elastic and scalable  3. 主机          host / instance  4. 硬盘          hard disk/ volume  5. 密钥          key  6. 公开密钥      public key  7. 映像          image / mapping  8. 负载均衡      load balancing  9. 对象存储      object storage  10. 弹性计算      elastic computing  11. 按秒计费   &nb…

Read More Read More

如何构建以应用为中心的“Kubernetes”?

如何构建以应用为中心的“Kubernetes”?

閱讀本文約花費: 23 (分鐘)在上篇文章《上 Kubernetes 到底有什么业务价值?》,主要和大家介绍了上 Kubernetes 有什么业务价值,以及什么是“以应用为中心”的 Kubernetes。本文将跟大家具体分享如何构建“以应用为中心”的 Kubernetes。 如何构建“以应用为中心”的 Kubernetes? 构建这么一个以用户为中心的 Kubernetes,需要做几个层级的事情。 1. 应用层驱动 首先来看最核心的部分,上图中蓝色部分,也就是 Kubernetes。可以在 Kubernetes 之上定义一组 CRD 和 Controller。可以在 CRD 来做用户这一侧的 API,比如说 pipeline 就是一个 API,应用也是一个 API。像运维侧的扩容策略这些都是可以通过 CRD 的方式安装起来。 2. 应用层抽象 所以我们的需要解决第一个问题是应用抽象。如果在 Kubernetes 去做应用层抽象,就等同于定义 CRD 和 Controller,所以 Controller 可以叫做应用层的抽象。本身可以是社区里的,比如 Tekton,istio 这些,可以作为你的应用驱动层。这是第一个问题,解决的是抽象的问题。不是特别难。 3. 插件能力管理 很多功能不是 K8s 提供的,内置的 Controller 还是有限的,大部分能力来自于社区或者是自己开发的 …

Read More Read More

Scroll Up