Browsed by
标签:缓存

WebSocket从入门到精通,半小时就够!

WebSocket从入门到精通,半小时就够!

閱讀本文約花費: 27 (分鐘)自从HTML5里的WebSocket出现后,彻底改变了以往Web端即时通讯技术的基础通道这个“痛点”(在此之前,开发者们不得不弄出了诸如:短轮询、长轮询、Comet、SSE等技术,可谓苦之久矣…),如今再也不用纠结到底该用“轮询”还是“Comet”技术来保证数据的实时性了,幸福来得就是如此突然 ^-^。 WebSocket如今不仅在Web应用里使用广泛,也慢慢被开发者们应用到各种那些原本使用TCP、UDP这类协议的富客户端(比如移动端中)。 有鉴于此,对于即时通讯方向的开发者来说,全面深入的了解WebSocket是非常有必要的,面试时也少不了会考察这方面的知识。 所以,即时通讯网在建站至今的几年时间里,持续整理了一大批跟Web端即时通讯有关的技术文章(这基中尤其WebSocket方面的文章最多)。本文也是一篇关于WebSocket从入门到精通的文章,内容由浅入深,比较适合想要在短时间内较深入的了解WebSocket协议的开发者学习。 《WebSocket详解(一):初步认识WebSocket技术》 《WebSocket详解(二):技术原理、代码演示和应用案例》 《WebSocket详解(三):深入WebSocket通信协议细节》 《WebSocket详解(四):刨根问底HTTP与WebSocket的关系(上篇)》 《WebSocket详解…

Read More Read More

别让自己“墙”了自己

别让自己“墙”了自己

閱讀本文約花費: 19 (分鐘)这一两周与几个朋友聊天,有年轻的90后,也有大叔级的70后,这些人在我看来都是很有能力的人,但是一些喜好过于强烈,让我不经意地回顾了我工作20年来身边的人,有发展得好的,也有发展的不好的,有些人是很可惜的,因为限制他们的不是其它人,也不是环境,而是自己,所以,很想写下这篇文章。(注:这篇文章可能会是一篇说教的文章,所以,可能会让你看着犯困,所以,我会尽量地短一些,而且尽可能多讲故事,少道理,这里的故事,全是真实发生的) 几个故事 2019年年初,我面试了一个很年轻的小伙子(93/94年出生),这个小伙子特别有灵性,也很聪明,计算机专业出身,也很喜欢技术,基础和学习能力也很好。在我这20年来认识的人中,如果他能呆在北京、上海、深圳这样的城市,我保证不出三年,他会成为他们同龄人中非常出色的技术人员,如果有个好的舞台有一个好的团队带他,他的未来会非常成功。然而,这个小伙子有两大喜好:1)只愿(或是说被迫)呆在一个毫无IT的环境的三/四线城市,2)对技术有非常大的偏好,只喜欢Go语言,非常不喜欢其它的语言,比如:Java(离开Java的世界,基本上离开了做架构的世界(相关解释见文末))。 他的这两个喜好,足以让一个未来会很优秀的人毁掉,因为,这个时代没有限制他,他的能力也没有限制他,但是他的意识完完全全地限制了他。 他把自己最宝贵的青春放在了很烂的项目上,就…

Read More Read More

最常用的Java框架或者开源项目有哪些?

最常用的Java框架或者开源项目有哪些?

閱讀本文約花費: 19 (分鐘)系统设计 微服务/分布式 基础框架 Spring Boot [1] :Spring Boot 可以轻松创建独立的生产级基于 Spring 的应用程序,内置 web 服务器让你可以像运行普通 Java 程序一样运行项目。另外,大部分 Spring Boot 项目只需要少量的配置即可,这有别于 Spring 的重配置。 spring-cloud-alibaba[2] : Spring Cloud Alibaba 致力于提供微服务开发的一站式解决方案。此项目包含开发分布式应用微服务的必需组件,方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。 Spring Cloud Alibaba Sentinel[3] :A lightweight powerful flow control component enabling reliability and monitoring for microservices. (轻量级的流量控制、熔断降级 Java 库)。 Dubbo[4] :Apache Dubbo 是一个基于 Java 的高性能开源 RPC 框架。 Nacos[5] :Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集,帮…

Read More Read More

程序员如何把控自己的职业

程序员如何把控自己的职业

閱讀本文約花費: 26 (分鐘)这篇文章的主要内容主要是我今年3月份在腾讯做的直播,主要是想让一些技术人员对世界有一个大体的认识,并且在这个认识下能够有一个好的方法成就自己。而不是在一脸蒙圈的状态下随波逐流,而日益迷茫和焦虑。直播完后,腾讯方面把我的直播形成文字的形式发了出来,我觉得我可以再做一个精编版。所以,有了这篇文章,希望对大家有帮助。 对我来说,在我二十多年的工作经历来看,期间经历了很多技术的更新换代,整个技术模式、业务模式也是一直变来变去,我们这群老程序员成长中所经历的技术比今天的程序员玩的还更杂更多。我罗列一下我学过的,而且还被淘汰掉的技术,大家先感受一下。 – MIS应用开发:FoxPro,PowerBuilder,Delphi – OA:Lotus Notes,VBScripts – 微软:ODBC/ADO,COM/DCOM,MFC/ATL,J++ – 服务器:AIX,HP-UX,SCO Unix – Web:CGI,ISAPI,SOAP – RPC:CICS,Tuxedo – J2EE:Websphere,Weblogic – DB:Sybase,Informix 我想说的是,无论过去还是今天,我们这些前浪和你们后浪所面对的技术的挑战和对技术的焦虑感是相似的,我们那个时候不但玩996,还玩封闭开发(就是一周只能回家一天)。当然,唯一好的东西,就是比起今天的程序员来…

Read More Read More

架构设计-谈谈架构

架构设计-谈谈架构

閱讀本文約花費: 32 (分鐘) 本文首先介绍了架构的概念定义,并介绍如何针对当前需求,选择合适的应用架构,希望对您的学习有所帮助。 1、什么是架构和架构本质 在软件行业,对于什么是架构,都有很多的争论,每个人都有自己的理解。 此君说的架构和彼君理解的架构未必是一回事。因此我们在讨论架构之前,我们先讨论架构的概念定义,概念是人认识这个世界的基础,并用来沟通的手段,如果对架构概念理解不一样,那沟通起来自然不顺畅。 Linux有架构,MySQL有架构,JVM也有架构,使用Java开发、MySQL存储、跑在Linux上的业务系统也有架构,应该关注哪一个?想要清楚以上问题需要梳理几个有关系又相似的概念:系统与子系统、模块与组建、框架与架构: 一、系统与子系统 系统:泛指由一群有关联的个体组成,根据某种规则运作,能完成个别元件不能独立完成的工作能力的群体。 子系统:也是由一群关联的个体组成的系统,多半是在更大的系统中的一部分。 二、模块与组件 都是系统的组成部分,从不同角度拆分系统而已。模块是逻辑单元,组件是物理单元。 模块就是从逻辑上将系统分解, 即分而治之, 将复杂问题简单化。模块的粒度可大可小, 可以是系统,几个子系统、某个服务,函数, 类,方法、 功能块等等。 组件可以包括应用服务、数据库、网络、物理机、还可以包括MQ、容器、Nginx等技术组件。 三、框架与架构 框架是组件实现的规…

Read More Read More

软件架构万字漫谈:业务架构、应用架构与云基础架构

软件架构万字漫谈:业务架构、应用架构与云基础架构

閱讀本文約花費: 34 (分鐘) 本文首先介绍了架构的分类以及架构模式与架构风格其次介绍了DDD 领域驱动设计和微服务与云原生架构,最后介绍 Kuberentes 应用,了解详情请阅读下文。本文来自于知乎,由火龙果软件Alice编辑、推荐。 软件开发就是把一个复杂的问题分解为一系列简单的问题,再把一系列简单的解决方案组合成一个复杂的解决方案。而软件开发中最大的挑战,就是即能够快速高效地针对需求、环境的变化做出改变,也能够持续提供稳定、高可用的服务。而软件架构,就是软件系统的骨骼与框架。 所谓架构,见仁见智,很难有一个明确或标准的定义;但架构并非镜花水月或阳春白雪,有系统的地方就需要架构,大到航空飞机,小到一个电商系统里面的一个功能组件,都需要设计和架构。抽象而言,架构就是对系统中的实体以及实体之间的关系所进行的抽象描述,是对物/信息的功能与形式元素之间的对应情况所做的分配,是对元素之间的关系以及元素同周边环境之间的关系所做的定义。架构能将目标系统按某个原则进行切分,切分的原则,是要便于不同的角色进行并行工作,结构良好的创造活动要优于毫无结构的创造活动。 软件架构的核心价值,即是控制系统的复杂性,将核心业务逻辑和技术细节的分离与解耦。软件架构是系统的草图,它描述的对象是直接构成系统的抽象组件;各个组件之间的连接则明确和相对细致地描述组件之间的通信。在实现阶段,这些抽象组件被细化为实际…

Read More Read More

账户中心 – 银行业务中台设计

账户中心 – 银行业务中台设计

閱讀本文約花費: 21 (分鐘) 本文主要介绍基于业务中台思想下的一种银行账户能力设计模式,在文中称之为“账户中心”。 账户能力是银行最基础的核心能力,银行所提供绝的大部分金融服务和金融产品都需要基于银行账户,因此也通常将账户能力落地的系统称为“银行核心系统”。 一、核心设计思想 账户中心的核心设计思想可以总结为:产品与账户分离、介质与账户分离、账户与账户分离。要理解账户中心的设计模式,必须先要理解并接受这3个设计思想,以下将逐一进行详细说明。 产品与账户分离 首先要先搞清楚产品和账户的区别,以下以购买银行理财产品来说明产品和账户的关系: 上图简要说明了客户购买理财产品、期间理财收益结算、赎回理财产品的流程: 在购买流程中,银行从客户个人账户(储蓄卡)上扣除了购买资金,按照对应的理财产品规则换算出可购买的理财份额,并将份额存入客户的理财分户中; 银行在产品运作期间,将按理财产品规则对客户持有的理财份额进行计算,将投资收益换算增加的理财份额存入理财分户(或换算为收益资金直接存入个人账户); 在赎回流程中,银行从客户理财分户取出产品份额,根据理财产品规则换算出对应的资金(以及对应的收益),将资金存入客户个人账户中。 上面的示例中,个人账户、理财分户是我们所指的账户,理财产品规则就是我们所指的产品。我们可以简单总结一下这两个概念:账户指用于登记及管理某一事物所留存数量的特殊账号;产品特指…

Read More Read More

我是Redis,MySQL大哥被我害惨了

我是Redis,MySQL大哥被我害惨了

閱讀本文約花費: 10 (分鐘)我是Redis 你好,我是Redis,一个叫Antirez的男人把我带到了这个世界上。 说起我的诞生,跟关系数据库MySQL还挺有渊源的。 在我还没来到这个世界上的时候,MySQL过的很辛苦,互联网发展的越来越快,它容纳的数据也越来越多,用户请求也随之暴涨,而每一个用户请求都变成了对它的一个又一个读写操作,MySQL是苦不堪言。尤其是到“双11”、“618“这种全民购物狂欢的日子,都是MySQL受苦受难的日子。 据后来MySQL告诉我说,其实有一大半的用户请求都是读操作,而且经常都是重复查询一个东西,浪费它很多时间去进行磁盘I/O。 后来有人就琢磨,是不是可以学学CPU,给数据库也加一个缓存呢?于是我就诞生了! 出生不久,我就和MySQL成为了好朋友,我们俩常常携手出现在后端服务器中。 应用程序们从MySQL查询到的数据,在我这里登记一下,后面再需要用到的时候,就先找我要,我这里没有再找MySQL要。 为了方便使用,我支持好几种数据结构的存储: String Hash List Set SortedSet Bitmap ······ 因为我把登记的数据都记录在内存中,不用去执行慢如蜗牛的I/O操作,所以找我要比找MySQL要省去了不少的时间呢。 可别小瞧这简单的一个改变,我可为MySQL减轻了不小的负担!随着程序的运行,我缓存的数据越来越多,有相当部…

Read More Read More

Kubernetes Informer 机制源码解析

Kubernetes Informer 机制源码解析

閱讀本文約花費: 14 (分鐘)这篇文章来源于云原生社区组织的 Kubernetes 源码研习社的作业,是个人学习Informer机制、理解Informer各个组件的设计的总结。 背景 为什么Kubernetes需要Informer机制?我们知道Kubernetes各个组件都是通过REST API跟API Server交互通信的,而如果每次每一个组件都直接跟API Server交互去读取/写入到后端的etcd的话,会对API Server以及etcd造成非常大的负担。而Informer机制是为了保证各个组件之间通信的实时性、可靠,并且减缓对API Server和etcd的负担。 Informer 流程 这个流程,建议先看看《From Controller Study Informer》 这里我们以CoreV1. Pod资源为例子: 第一次启动Informer的时候,Reflector 会使用 List从API Server主动获取CoreV1. Pod的所有资源对象信息,通过 resync将资源存放在 Store中 持续使用 Reflector建立长连接,去 Watch API Server发来的资源变更事件 当2 监控到CoreV1.Pod的资源对象有增加删除修改之后,就把资源对象存放在 DeltaFIFO中,…

Read More Read More

苏宁高时效、高并发秒杀业务中台的设计与实现

苏宁高时效、高并发秒杀业务中台的设计与实现

閱讀本文約花費: 20 (分鐘) 文章主要介绍了苏宁架构设计背景,苏宁的架构设计以及系统多活部署与单机房宕机场景下的降级方案 设计背景 对于苏宁易购主站而言,正常的用户购物流程囊括选品、下单、库存扣减、付款、订单状态更新、物流履约等。但是在电商业务中往往会涉及到对某些热点商品的秒杀场景。相比于正常购物流程,秒杀场景具有时效性高、并发量大、瞬时业务量极高的业务特性,往往会出现显著的分布式一致性问题。正常的业务系统不能很好地应对瞬时高并发的业务需求,因此就需要针对于秒杀场景进行相应的架构优化,抑或是设计专门用于秒杀的中台业务系统。 就秒杀业务而言,系统在瞬时会达到极高的并发量,如果与其它业务耦合,那么势必会对其它业务造成风险,因此基于安全性考虑和业务隔离原则,秒杀系统在设计上应该与其它系统充分解耦,单独部署。本文将讨论在苏宁现有的技术架构和中台组件的基础上,如何去实现一个通用型秒杀业务中台。 架构设计 1. 系统前端与负载层设计 图一:前端与负载层设计 鉴于秒杀业务本身的高并发特性,对用户请求进行前端分流是必不可少的一步。在系统上游就对部分用户请求进行处理,可以避免海量请求对后端服务器产生过大压力。因为用户往往在秒杀前几分钟就开始点击下单按钮,因此在秒杀开始前可以使用静态资源页面,用户请求由 CDN 直接响应,不必到达后端服务器。 此外,由于秒杀业务的高时效性特征,下单窗口基本集中在秒…

Read More Read More

Medium开发团队谈架构设计

Medium开发团队谈架构设计

閱讀本文約花費: 16 (分鐘) 背景   说到底,Medium是个社交网络,人们可以在这里分享有意思的故事和想法。据统计,目前累积的用户阅读时间已经超过14亿分钟,合两千六百年。   我们支持着每个月两千五百万的读者以及每周数以万计的文章发布。我们不想Medium的文章以阅读量为成功的依据,而是观点取胜。在Medium,文章的观点比作者的名头更重要。在这里,对话促进想法,并且很看重文字的力量。   我是Medium开发团队的负责人,此前在Google工作,负责开发Google+和Gmail,还创立了Closure项目。业余时间我喜欢滑雪跳伞和丛林冒险。   团队介绍   说起团队我非常自豪,这是一群富有好奇心而且想法丰富的天才,大家凑到一块是想做大事的。   团队以跨功能的任务驱动,这样每个人既可以专攻,又可以毫无压力的对整个架构有所贡献。我们的理念就是接触的方面越多,对团队的锻炼越大。更多关于团队的理念见此。   在工作组织方面,我们有着很大的自由度,当然作为一个公司组成,我们还是有季度目标的,并且鼓励敏捷开发模式。我们使用GitHub进行code review和问题跟踪,用Google Apps作为邮件、文档和表单系统。跟很多团队习惯使用Trello不同,我们是Slack和slack机器人的重度用户。   原始架构   最开始的时候,Medium部署在EC2上,用Node.j…

Read More Read More

四层和七层负载均衡的区别

四层和七层负载均衡的区别

閱讀本文約花費: 33 (分鐘)(一) 简单理解四层和七层负载均衡: ① 所谓四层就是基于IP+端口的负载均衡;七层就是基于URL等应用层信息的负载均衡;同理,还有基于MAC地址的二层负载均衡和基于IP地址的三层负载均衡。 换句换说,二层负载均衡会通过一个虚拟MAC地址接收请求,然后再分配到真实的MAC地址;三层负载均衡会通过一个虚拟IP地址接收请求,然后再分配到真实的IP地址;四层通过虚拟IP+端口接收请求,然后再分配到真实的服务器;七层通过虚拟的URL或主机名接收请求,然后再分配到真实的服务器。   ② 所谓的四到七层负载均衡,就是在对后台的服务器进行负载均衡时,依据四层的信息或七层的信息来决定怎么样转发流量。 比如四层的负载均衡,就是通过发布三层的IP地址(VIP),然后加四层的端口号,来决定哪些流量需要做负载均衡,对需要处理的流量进行NAT处理,转发至后台服务器,并记录下这个TCP或者UDP的流量是由哪台服务器处理的,后续这个连接的所有流量都同样转发到同一台服务器处理。七层的负载均衡,就是在四层的基础上(没有四层是绝对不可能有七层的),再考虑应用层的特征,比如同一个Web服务器的负载均衡,除了根据VIP加80端口辨别是否需要处理的流量,还可根据七层的URL、浏览器类别、语言来决定是否要进行负载均衡。举个例子,如果你的Web服务器分成两组,一组是中文语言的…

Read More Read More

负载均衡基础知识

负载均衡基础知识

閱讀本文約花費: 18 (分鐘)一、什么是负载均衡?  互联网早期,业务流量比较小并且业务逻辑比较简单,单台服务器便可以满足基本的需求;但随着互联网的发展,业务流量越来越大并且业务逻辑也越来越复杂,单台机器的性能问题以及单点问题凸显了出来,因此需要多台机器来进行性能的水平扩展以及避免单点故障。但是要如何将不同的用户的流量分发到不同的服务器上面呢?  早期的方法是使用DNS做负载,通过给客户端解析不同的IP地址,让客户端的流量直接到达各个服务器。但是这种方法有一个很大的缺点就是延时性问题,在做出调度策略改变以后,由于DNS各级节点的缓存并不会及时的在客户端生效,而且DNS负载的调度策略比较简单,无法满足业务需求,因此就出现了负载均衡。  客户端的流量首先会到达负载均衡服务器,由负载均衡服务器通过一定的调度算法将流量分发到不同的应用服务器上面,同时负载均衡服务器也会对应用服务器做周期性的健康检查,当发现故障节点时便动态的将节点从应用服务器集群中剔除,以此来保证应用的高可用。  负载均衡又分为四层负载均衡和七层负载均衡。四层负载均衡工作在OSI模型的传输层,主要工作是转发,它在接收到客户端的流量以后通过修改数据包的地址信息将流量转发到应用服务器。  七层负载均衡工作在OSI模型的应用层,因为它需要解析应用层流量,所以七层负载均衡在接到客户端的流量以后,还需要一个完整的TCP/IP协议栈。…

Read More Read More

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

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

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

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

Read More Read More

Scroll Up