Browsed by
分类:其它

五分钟理解一致性哈希算法(consistent hashing)

五分钟理解一致性哈希算法(consistent hashing)

閱讀本文約花費: 9 (分鐘)   一致性哈希算法在1997年由麻省理工学院提出的一种分布式哈希(DHT)实现算法,设计目标是为了解决因特网中的热点(Hot spot)问题,初衷和CARP十分类似。一致性哈希修正了CARP使用的简 单哈希算法带来的问题,使得分布式哈希(DHT)可以在P2P环境中真正得到应用。     一致性hash算法提出了在动态变化的Cache环境中,判定哈希算法好坏的四个定义:1、平衡性(Balance):平衡性是指哈希的结果能够尽可能分布到所有的缓冲中去,这样可以使得所有的缓冲空间都得到利用。很多哈希算法都能够满足这一条件。2、单调性(Monotonicity):单调性是指如果已经有一些内容通过哈希分派到了相应的缓冲中,又有新的缓冲加入到系统中。哈希的结果应能够保证原有已分配的内容可以被映射到原有的或者新的缓冲中去,而不会被映射到旧的缓冲集合中的其他缓冲区。 3、分散性(Spread):在分布式环境中,终端有可能看不到所有的缓冲,而是只能看到其中的一部分。当终端希望通过哈希过程将内容映射到缓冲上时,由于不同终端所见的缓冲范围有可能不同,从而导致哈希的结果不一致,最终的结果是相同的内容被不同的终端映射到不同的缓冲区中。这种情况显然是应该避免的,因为它导致相同内容被存储到不同缓冲中去,降低了系统存储的效…

Read More Read More

再有人问你分布式事务,把这篇扔给他

再有人问你分布式事务,把这篇扔给他

閱讀本文約花費: 24 (分鐘)前言 不知道你是否遇到过这样的情况,去小卖铺买东西,付了钱,但是店主因为处理了一些其他事,居然忘记你付了钱,又叫你重新付。又或者在网上购物明明已经扣款,但是却告诉我没有发生交易。这一系列情况都是因为没有事务导致的。这说明了事务在生活中的一些重要性。有了事务,你去小卖铺买东西,那就是一手交钱一手交货。有了事务,你去网上购物,扣款即产生订单交易。 事务的具体定义 事务提供一种机制将一个活动涉及的所有操作纳入到一个不可分割的执行单元,组成事务的所有操作只有在所有操作均能正常执行的情况下方能提交,只要其中任一操作执行失败,都将导致整个事务的回滚。简单地说,事务提供一种“要么什么都不做,要么做全套(All or Nothing)”机制。 数据库本地事务 ACID 说到数据库事务就不得不说,数据库事务中的四大特性,ACID: A:原子性(Atomicity) 一个事务(transaction)中的所有操作,要么全部完成,要么全部不完成,不会结束在中间某个环节。事务在执行过程中发生错误,会被回滚(Rollback)到事务开始前的状态,就像这个事务从来没有执行过一样。 就像你买东西要么交钱收货一起都执行,要么要是发不出货,就退钱。 C:一致性(Consistency) 事务的一致性指的是在一个事务执行之前和执行之后数据库都必须处于一致性状态。如果事务成功地完成,那么…

Read More Read More

常用的分布式事务解决方案

常用的分布式事务解决方案

閱讀本文約花費: 46 (分鐘)众所周知,数据库能实现本地事务,也就是在同一个数据库中,你可以允许一组操作要么全都正确执行,要么全都不执行。这里特别强调了本地事务,也就是目前的数据库只能支持同一个数据库中的事务。但现在的系统往往采用微服务架构,业务系统拥有独立的数据库,因此就出现了跨多个数据库的事务需求,这种事务即为“分布式事务”。那么在目前数据库不支持跨库事务的情况下,我们应该如何实现分布式事务呢?本文首先会为大家梳理分布式事务的基本概念和理论基础,然后介绍几种目前常用的分布式事务解决方案。废话不多说,那就开始吧~ 什么是事务? 事务由一组操作构成,我们希望这组操作能够全部正确执行,如果这一组操作中的任意一个步骤发生错误,那么就需要回滚之前已经完成的操作。也就是同一个事务中的所有操作,要么全都正确执行,要么全都不要执行。 事务的四大特性 ACID 说到事务,就不得不提一下事务著名的四大特性。 原子性 原子性要求,事务是一个不可分割的执行单元,事务中的所有操作要么全都执行,要么全都不执行。 一致性 一致性要求,事务在开始前和结束后,数据库的完整性约束没有被破坏。 隔离性 事务的执行是相互独立的,它们不会相互干扰,一个事务不会看到另一个正在运行过程中的事务的数据。 持久性 持久性要求,一个事务完成之后,事务的执行结果必须是持久化保存的。即使数据库发生崩溃,在数据库恢复后事务提交的结果…

Read More Read More

定时任务高效触发

定时任务高效触发

閱讀本文約花費: 4 (分鐘)开发中我们经常会遇到一些需要定时来解决的业务场景。比如,有这样一个需求:“如果连续30s没有请求包(例如登录,消息,keepalive包),服务端就要将这个用户的状态置为离线”。 轮询处理 将所有任务都添加到某集合中,定时轮询扫描,如果达到条件则进行相关处理; 方案的不足: 效率低下。已经被执行过记录,仍然会被扫描(只是不会出现在结果集中),存在大量的重复计算; 时效性差。时间误差取决于轮询的间隔;如果间隔过小,重复被扫描的次数更高,效率会变得更低下。 定时处理 每来一个任务,启动一个定时器,达到定时器时间,执行相关处理; 方案的不足: 定时数过多,导致内存使用率过高,容易导致崩溃。 环形队列处理 数据结构: 环形队列ListLoop,例如可以创建一个包含0-30的slot**环形队列**(本质是个数组); 每个环上的任务集合Slot,环上每一个slot是一个Set; 记录每个Task对应落到Slot的Map集合; 执行过程:第一步:启动一个timer,每隔1s,在上述环形队列中移动一格,0->1->2->3…->29->30->0…有一个CurrentSlotIndex指针来标识刚检测过的slot ;第二步:当有某用户uid有请求包到达时,从Map结构中,查找出这个uid存储在哪一个slot里;第三步:如果存在,从…

Read More Read More

优惠券系统应该如何设计?

优惠券系统应该如何设计?

閱讀本文約花費: 9 (分鐘)双十一节日气氛已经愈演愈烈了,优惠券已经成为了绝对的关键词,近两周一直在做优惠券需求,从最初的一无所知到现在建立初步的优惠券框架结构,一路也是磕磕碰碰。今天就把这段时间的输入总结一下然后输出。 优惠券的投放方式有多种,本文采用的是活动页送券这种形式。 一、创建优惠券 优惠券是一套规则的组合,创建优惠券是优惠券系统设计的第一步,主要有以下几部分组成:基本信息、优惠类型、使用范围、有效期等。 基本信息包括优惠券名称、发放数量、优惠券是否可叠加、每人限领张数、是否和其他促销同时使用(优惠优先级)、使用规则等。 优惠类型 优惠类型要根据公司实际情况和用户群体去设计,主要有满减、立减、折扣券或优惠码。满减、立减、折扣券属于私有券,只能个人账号使用;优惠码属于共有券,给有兑换码并且兑换的用户使用。 使用范围 使用优惠券的用户类型、使用优惠券的商品类型、订单类型。用户类型一般指是否区分新老用户、不同的等级用户;商品类型指哪些区域、哪些品类的商品可使用;订单类型指订单满多少元可使用、满多少件可使用。 有效期 有效期一般有两种: 一种是固定的有效期,设定一个时间段;另一种是设定一个有效数,比如:30天,一般是从领取之日起30天内有效。多数情况下都会选择第二种,增加紧迫感,促进用户下单。优惠券因涉及金额,通常需要财务审批,财务审批后优惠券ID生成。到此,优惠券的基本规则大…

Read More Read More

一致性hash算法简介

一致性hash算法简介

閱讀本文約花費: 5 (分鐘)一致性哈希算法在1997年由麻省理工学院提出的一种分布式哈希(DHT)实现算法,设计目标是为了解决因特网中的热点(Hot spot)问题,初衷和CARP十分类似。一致性哈希修正了CARP使用的简单哈希算法带来的问题,使得分布式哈希(DHT)可以在P2P环境中真正得到应用。 一致性hash算法提出了在动态变化的Cache环境中,判定哈希算法好坏的四个定义: 1、平衡性(Balance):平衡性是指哈希的结果能够尽可能分布到所有的缓冲中去,这样可以使得所有的缓冲空间都得到利用。很多哈希算法都能够满足这一条件。 2、单调性(Monotonicity):单调性是指如果已经有一些内容通过哈希分派到了相应的缓冲中,又有新的缓冲加入到系统中。哈希的结果应能够保证原有已分配的内容可以被映射到原有的或者新的缓冲中去,而不会被映射到旧的缓冲集合中的其他缓冲区。 3、分散性(Spread):在分布式环境中,终端有可能看不到所有的缓冲,而是只能看到其中的一部分。当终端希望通过哈希过程将内容映射到缓冲上时,由于不同终端所见的缓冲范围有可能不同,从而导致哈希的结果不一致,最终的结果是相同的内容被不同的终端映射到不同的缓冲区中。这种情况显然是应该避免的,因为它导致相同内容被存储到不同缓冲中去,降低了系统存储的效率。分散性的定义就是上述情况发生的严重程度。好的哈希算法应能够尽量避免不…

Read More Read More

去阿里面试被问:如果是MySQL引起的CPU消耗过大,你会如何优化?

去阿里面试被问:如果是MySQL引起的CPU消耗过大,你会如何优化?

閱讀本文約花費: 4 (分鐘) 链接:https://www.cnblogs.com/YangJiaXin/p/10933458.html 目录 谁在消耗cpu?祸首是谁? 用户 IO等待 产生影响 如何减少CPU消耗? 减少等待 减少计算 升级cpu 谁在消耗cpu? 用户+系统+IO等待+软硬中断+空闲 image image 祸首是谁? 用户 用户空间CPU消耗,各种逻辑运算 正在进行大量tps函数/排序/类型转化/逻辑IO访问… 用户空间消耗大量cpu,产生的系统调用是什么?那些函数使用了cpu周期? IO等待 等待IO请求的完成 此时CPU实际上空闲 如vmstat中的wa 很高。但IO等待增加,wa也不一定会上升(请求I/O后等待响应,但进程从核上移开了) image image 产生影响 用户和IO等待消耗了大部分cpu 吞吐量下降(tps) 查询响应时间增加 慢查询数增加 对mysql的并发陡增,也会产生上诉影响 image 如何减少CPU消耗? 减少等待 减少IO量 SQL/index,使用合适的索引减少扫描的行数(需平衡索引的正收益和维护开销,空间换时间) 提升IO处理能力 加cache/加磁盘/SSD image 减少计算 减少逻辑运算量 避免使用函数,将运算转移至易扩展的应用服务器中如substr等字符运算,dateadd/datesub等日期运算,abs等…

Read More Read More

苹果放弃英特尔芯片,为什么会打击美国计算机产业?

苹果放弃英特尔芯片,为什么会打击美国计算机产业?

閱讀本文約花費: 16 (分鐘)今年6月22日,苹果公司在一年一度的全球开发者大会 WWDC 上,宣布彻底放弃英特尔公司(Intel)的 CPU,改用自己设计的 ARM 芯片。 上一篇文章已经分析过了,苹果为什么要这样做。主要原因是,整个苹果战略是围绕移动端(iPhone)构建的,它现在想把移动端和桌面端合成一个生态,自己完全控制所有硬件和软件,不愿再让 CPU 这样的核心部件受制于英特尔了。 今天接着往下谈,这个”换芯”决定有什么后果。 表面上看,这是苹果公司的”家务事”,但是实际上牵动各方的利益,产生一系列的连锁反应,动摇长久以来主导行业的 Wintel 联盟,甚至会影响到美国的竞争优势。 一、英特尔的反应 苹果宣布换芯以后,英特尔仅仅发了一个简短的声明。 “苹果公司与我们有多个业务领域的合作,我们将继续为他们提供支持。……我们相信,基于 Intel 的 PC 将为全球客户提供最佳的体验。” 言下之意,这只是一件小事,不用大惊小怪。市场似乎也同意这种观点,英特尔股价当天小幅下跌,没过几天又涨回去了。 为什么英特尔觉得影响不大? 因为它的利润主要来自服务器 CPU,2019年占到利润总额的一半。个人电脑 CPU 的利润只占到三分之一,而 MacOS 只占全世界桌面操作系统市场的17%,…

Read More Read More

使用Kubernetes实现高级调度技术

使用Kubernetes实现高级调度技术

閱讀本文約花費: 14 (分鐘)使用Kubernetes这样的高级容器编排工具的优势之一就是,它的调度程序非常灵活。这为用户提供了广泛的选择,可以用来指定将Pod分配给满足条件的特定工作站节点的环境,而不仅仅基于节点的可用资源。为了解释Kubernetes如何决定将pod放置在正确的主机上,我们可以看一下Kubernetes master及一些组件的简化图: 主API(kube-apiserver)是一种提供对集群需求和当前状态进行读/写的工具。像调度程序这样的组件可以使用主API检索当前状态信息,应用一些逻辑和计算,并使用有关所需状态的新信息更新API(例如,指定要将哪个节点安排到新pod,或者指定哪个pod应该移动到另一个节点)。另外,集群用户和管理员可以更新集群状态或通过Kubernetes仪表板查看它,该仪表板对外提供API。CI / CD管道还可以使用API创建新资源或修改现有资源。 其他调用api的主要角色是名为“kubelets”的代理节点,它在工作节点上管理容器运行状态(通常为Docker)。当Kubelet判断出要报告的主机预期状态与其实际状态之间存在差异时,它将启动或终止需要的容器以达到主API描述的目标状态。Kubelets经常查询API,或者观察它们的变化,这就是为什么Kubernetes对更新和更改的响应几乎是即时的。(几秒钟)。 正如我们所看到的,Kub…

Read More Read More

苹果电脑为什么要换 CPU:Intel 与 ARM 的战争

苹果电脑为什么要换 CPU:Intel 与 ARM 的战争

閱讀本文約花費: 12 (分鐘)三个月前,新款 iPad Pro 发布,支持触摸板和鼠标。 上图的黑点就是鼠标。苹果公司显然打算,平板电脑当作笔记本使用。 我们知道,iPad 的操作系统跟 iPhone 是一样的,都是基于 iOS。如果 iOS 可以用于笔记本,就意味着可以跟桌面系统 MacOS 统一了。如果 MacBook 和 iPhone 都用同一个操作系统,App 就能通用了。 苹果公司显然也是这么打算的。几天后的6月22日将举行 WWDC(苹果全球开发者大会)。媒体报道,苹果公司将在那一天宣布,更换 Mac 电脑的 CPU,从 Intel 公司的 x86 架构改成 ARM 架构。 一旦 Mac 跟 iPhone 使用同样架构的 CPU,那就铺平了统一操作系统的道路。操作系统无法通用的最主要原因,就是 CPU 架构不同。 本文回顾苹果公司的 CPU 架构变化历史,帮助大家理解这件事的技术含义,以及未来的影响。 一、CPU 架构是什么 CPU 的全称是”中央处理单元”,它是计算机的核心,计算都由它来完成。但是,CPU 本身只是一个概念,每家芯片公司都有自己的具体实现。 不同的 CPU 设计实现,就称为” CPU 架构”(CPU architecture)。 不同的 CPU 架构有不同的指令集,彼此不通用,这导致运行在上面…

Read More Read More

微服务部署:蓝绿部署、滚动部署、灰度发布、金丝雀发布

微服务部署:蓝绿部署、滚动部署、灰度发布、金丝雀发布

閱讀本文約花費: 7 (分鐘) 在项目迭代的过程中,不可避免需要”上线“。上线对应着部署,或者重新部署;部署对应着修改;修改则意味着风险。 目前有很多用于部署的技术,有的简单,有的复杂;有的得停机,有的不需要停机即可完成部署。本文的目的就是将目前常用的布署方案做一个总结。 一、蓝绿布署 Blue/Green Deployment(蓝绿部署) 1、定义 蓝绿部署是不停老版本,部署新版本然后进行测试,确认OK,将流量切到新版本,然后老版本同时也升级到新版本。 1、特点 蓝绿部署无需停机,并且风险较小。 2、布署过程 第一步、部署版本1的应用(一开始的状态) 所有外部请求的流量都打到这个版本上。 image.png 第二步、部署版本2的应用 版本2的代码与版本1不同(新功能、Bug修复等)。 第三步、将流量从版本1切换到版本2。 image.png 第四步、如版本2测试正常,就删除版本1正在使用的资源(例如实例),从此正式用版本2。 3、小结 从过程不难发现,在部署的过程中,我们的应用始终在线。并且,新版本上线的过程中,并没有修改老版本的任何内容,在部署期间,老版本的状态不受影响。这样风险很小,并且,只要老版本的资源不被删除,理论上,我们可以在任何时间回滚到老版本。 4、蓝绿发布的注意事项 当你切换到蓝色环境时,需要妥当处理未完成的业务和新的业务。如果你的数据库后端无法处理,会是一个比较…

Read More Read More

部署策略对比:蓝绿部署、金丝雀发布及其他

部署策略对比:蓝绿部署、金丝雀发布及其他

閱讀本文約花費: 13 (分鐘)目前,软件开发最大的变化是部署频率。产品团队更早(更频繁)的将产品发布到生产环境。数月或者数年的发布周期变得越来越短 – 对那些构建纯软件产品的人来说更是如此。 现在,使用面向服务的架构和微服务方式,开发者可以设计模块化的代码库。这允许他们同时在代码库中不同的地方编写和部署代变更。 缩短部署周期的业务优势狠明显: 缩短上市时间 客户可以在更短的时间内获得产品价值 客户的反馈也会更快的到达产品团队,这意味着团队可以更快的迭代特性和修复问题 开发人员的整体士气会上升 但是,这种转变也给运维或者 DevOps 团队带来了新挑战。更频繁的部署,意味着已经部署的代码会对站点可用性和客户体验带来负面影响。这就是制定代码部署策略如此重要的原因,因为它可以最大限度的降低产品和客户的风险。 在本文中,我们将讨论不同的部署策略、最佳实践和工具,让你的团队可以更快更可靠的工作。 现代应用的挑战 现代应用通常是分布式的,基于云的。它们可以弹性扩展来满足需求,基于高可用架构更好地容错。这些应用可以使用全托管服务,例如 AWS Lambda 和 Elastic Container Service(ECS) 等平台处理一些运维责任。 这些应用经常频繁部署。例如,移动 app 和 web 应用可能一个月内经历多次更改。有些甚至一天…

Read More Read More

连接zookeeper时报”Path cannot be null”错误的解决方法

连接zookeeper时报”Path cannot be null”错误的解决方法

閱讀本文約花費: 3 (分鐘)   上周将公司生产环境中zookeeper集群中的一台zookeeper重启后,所有的连接此zookeeper的客户端都报如下错误: [ctvpay] 2018-03-23 10:57:08.569 — ERROR [main-EventThread] CuratorFrameworkImpl.java:529 – Watcherexceptionjava.lang.IllegalArgumentException: Path cannot be null        at org.apache.zookeeper.common.PathUtils.validatePath(PathUtils.java:45) ~[zookeeper-3.4.6.jar!/:3.4.6-1569965]        at org.apache.zookeeper.ZooKeeper.getChildren(ZooKeeper.java:1572) ~[zookeeper-3.4.6.jar!/:3.4.6-1569965]        at com.netflix.curator.framework…

Read More Read More

Kubernetes 下日志采集、存储与处理技术实践

Kubernetes 下日志采集、存储与处理技术实践

閱讀本文約花費: 25 (分鐘) 本文介绍了“Logtail + 日志服务 + 生态”架构,介绍了:Logtail客户端在Kubernetes日志采集场景下的优势. 日志服务作为基础设施一站式解决实时读写、HTAP两大日志强需求;日志服务数据的开放性以及与云产品、开源社区相结合,在实时计算、可视化、采集上为用户提供的丰富选择。 Kubernetes日志处理的趋势与挑战 Kubernetes的serveless化 Kubernetes容器技术促进了技术栈的去耦合,通过引入栈的分层使得开发者可以更加关注自身的应用程序和业务场景。从Kubernetes本身来看,这个技术解耦也在更进一步发展,容器化的一个发展的趋势是:这些容器都将会在无服务器的基础设施上运行。 谈到基础设施,首先可以联想到云,目前在AWS、阿里云、Azure的云上都提供了无服务器化的Kubernetes服务。在serverless Kubernetes上,我们将不再关心集群与机器,只需要声明容器的镜像、CPU、内存、对外服务方式就可以启动应用。 如上图,左右两边分别是经典Kubernetes、serverless Kubernetes的形态。在从左向右发展的过程中,日志采集也变得复杂: 1.在一个Kubernetes node上,可能会运行更大规模量级的pod,每个pod上都可能有日志或监控指标采集需求,意味着单node上…

Read More Read More

Scroll Up