关于高性能:thrift的网络传输性能和需要注意的问题

起源:thrift的网络传输性能和须要留神的问题thrift应该是目前反对编程语言品种最多的跨语言 rpc服务框架, http://thrift.apache.org/ thrift实现了残缺的网络服务,所以个别应用thrift时,会应用到thrift的服务框架。当然,也能够用本人曾经实现的网络服务,用io流对接thrift接口的输入输出流实现thrift的接入。 无论是用thrift的网络实现,还是本人实现的网络服务,只有对接thrift,在调用thrift接口实现rpc时,都是走thrift的网络传输方式。 thrift的网络传输实现形式 不适宜也不反对压力较大的网络传输需要。实际上,调用一次thrift接口,并不是只调一次网络io写数据,而是拆分为屡次写数据传送。 调用一个thrift 的接口发送数据时,thrift会将这个操作拆分为几个操作: 调用thrift的办法时:thrift会找到这个办法所在的对象,调用write办法, 在write办法在,别离对各个参数,顺次调用 writeFieldBegin,writeXXX(具体参数类型) ,WriteFieldStop 等函数每次调用也同时调用网络io写相应数据. 以目前最新的thrift-0.18.1实现为例 比方 go的实现: func (p *ItnetPonMergeArgs) Write(ctx context.Context, oprot thrift.TProtocol) error { if err := oprot.WriteStructBegin(ctx, "PonMerge_args"); err != nil { return thrift.PrependError(fmt.Sprintf("%T write struct begin error: ", p), err) } if p != nil { if err := p.writeField1(ctx, oprot); err != nil { return err } if err := p.writeField2(ctx, oprot); err != nil { return err } } if err := oprot.WriteFieldStop(ctx); err != nil { return thrift.PrependError("write field stop error: ", err) } if err := oprot.WriteStructEnd(ctx); err != nil { return thrift.PrependError("write struct stop error: ", err) } return nil}//第一个参数func (p *ItnetPonMergeArgs) writeField1(ctx context.Context, oprot thrift.TProtocol) (err error) { if err := oprot.WriteFieldBegin(ctx, "pblist", thrift.LIST, 1); err != nil { //WriteFieldBegin return thrift.PrependError(fmt.Sprintf("%T write field begin error 1:pblist: ", p), err) } if err := oprot.WriteListBegin(ctx, thrift.STRUCT, len(p.Pblist)); err != nil { return thrift.PrependError("error writing list begin: ", err) } for _, v := range p.Pblist { if err := v.Write(ctx, oprot); err != nil { return thrift.PrependError(fmt.Sprintf("%T error writing struct: ", v), err) } } if err := oprot.WriteListEnd(ctx); err != nil { return thrift.PrependError("error writing list end: ", err) } if err := oprot.WriteFieldEnd(ctx); err != nil { return thrift.PrependError(fmt.Sprintf("%T write field end error 1:pblist: ", p), err) } return err}//第二个参数,操作相似第一个参数func (p *ItnetPonMergeArgs) writeField2(ctx context.Context, oprot thrift.TProtocol) (err error) { if err := oprot.WriteFieldBegin(ctx, "id", thrift.I64, 2); err != nil { return thrift.PrependError(fmt.Sprintf("%T write field begin error 2:id: ", p), err) } if err := oprot.WriteI64(ctx, int64(p.ID)); err != nil { return thrift.PrependError(fmt.Sprintf("%T.id (2) field write error: ", p), err) } if err := oprot.WriteFieldEnd(ctx); err != nil { return thrift.PrependError(fmt.Sprintf("%T write field end error 2:id: ", p), err) } return err}调用Pon(ItnetPonMergeArgs)办法的thrift传输程序是: ...

September 6, 2023 · 3 min · jiezi

关于高性能:高性能网络-SIG-月度动态ANCK-首次支持-SMCv21virtio-规范支持隧道报文内头部哈希

高性能网络 SIG(Special Interest Group) :在云计算时代,软硬件高速倒退,云原生、微服务等新的利用状态衰亡,让更多的数据在过程之间流动,而网络则成为了这些数据流的载体,在整个云时代扮演着前所未有的重要角色。在这个万物互联的时代,云上的网络通信效率对各种服务至关重要,高性能网络趣味组致力于利用 XDP、RDMA、VIRTIO 等新高效通信技术,联合软硬件一体化的思维,打造高性能网络协议栈,晋升云计算时代数据中心利用的网络的性能。 01 SIG 整体停顿本月要害停顿: 1、SIG 本月实现 SMC 在 ANCK 5.10-015 内核的集成和公布,ANCK 成为社区首个实现 SMCv2.1 的内核。ANCK 中 SMC 反对 SMCv2.1 协定新增的链路数量协商、链路承载连贯数量协商、Vendor 能力拓展等个性,反对通过 AF_INET 协定族应用 SMC,反对局部场景基于 eBPF 的替换策略,以及其余多个优化与稳定性修复。 2、SIG 推动的对于隧道内头部哈希的 virtio 标准规范,通过 8 个月 445 封邮件的沟通,在本月终于胜利进入 virtio SPEC 主线。该提案基于特色协商的机制,为 virtio 提供了隧道报文内头部哈希的能力。 02 ANCK 内核网络修复ANCK 5.10-015 版本回合多个 SIG 提交至上游的修复补丁: net/smc: Reset connection when trying to use SMCRv2 failsnet/smc: Scan from current RMB list when no position specifiednet/smc: Dont use RMBs not mapped to new link in SMCRv2 ADD LINKnet/smc: Avoid to access invalid RMBs MRs in SMCRv1 ADD LINK CONT平安本月网络方向共计修复 13 个 CVE,笼罩 sched/iscsi_tcp/rxrpc/netfilter/tap 等模块,CVE 列表:ANCK-5.10:CVE-2023-3610,CVE-2023-2006,CVE-2023-2162,CVE-2023-35001,CVE-2023-31248,CVE-2023-3117,CVE-2023-1382。 ...

August 22, 2023 · 2 min · jiezi

关于高性能:高性能网络-SIG-月度动态联合-IBM-就-SMC-v21-协议升级达成一致ANCK-率先完成支持

高性能网络 SIG(Special Interest Group) :在云计算时代,软硬件高速倒退,云原生、微服务等新的利用状态衰亡,让更多的数据在过程之间流动,而网络则成为了这些数据流的载体,在整个云时代扮演着前所未有的重要角色。在这个万物互联的时代,云上的网络通信效率对各种服务至关重要,高性能网络趣味组致力于利用 XDP、RDMA、VIRTIO 等新高效通信技术,联合软硬件一体化的思维,打造高性能网络协议栈,晋升云计算时代数据中心利用的网络的性能。 01 SIG 整体停顿本月高性能网络 SIG 的次要工作聚焦在 ANCK 内核网络、SMC 和 virtio 上。 本月要害停顿: SIG 本月与 IBM SMC 团队就 SMCv2.1 协定的要害个性达成统一。SMCv2.1 较 SMCv1 具备更强的可拓展性,是 SMC 社区的将来发展趋势。SMCv2.1 相较 SMCv2 的次要差别是引入了 SIG 提出的:a) LGR 反对单 Link。b) LGR 反对协商最大连接数。c) 反对 RDMA write with immediate。d) 反对 vendor 特定个性等内容。 SIG 本月发动的 [Proposal] Relationship between XDP and rx-csum in virtio-net 提案解决了 virtio-net 反对 XDP 和 rx checksum 存在抵触的问题,实现了两者的共存。02 ANCK 内核网络修复修复了网卡多队列、大深度场景下产生 cpu stall 的问题:bugzilla 链接 https://bugzilla.openanolis.cn/show_bug.cgi?id=5383。 ...

June 19, 2023 · 2 min · jiezi

关于高性能:北邮基于焱融存储构建高性能智能医学研究平台

人工智能是引领新一轮科技反动、产业改革、社会倒退的战略性学科畛域,正在对人类生存、经济倒退和社会提高等方面产生重大深远的影响。北京邮电大学是国内最早从事人工智能人才培养和科学研究的单位之一,是中国人工智能学会(CAAI)的挂靠单位。“脑认知与智能医学系”是北京邮电大学人工智能学院的重要组成部分,正逐步倒退成为撑持该学院“智能+医学+X”交叉学科建设的重要力量,依靠脑认知与智能医学系,瞄准国家重大需要和人民生命衰弱,深度参加国家科技翻新2030-脑科学与类脑智能重大项目等。 AI 驱动 智能医疗大有可为当今信息技术蓬勃发展,医疗畛域的改革往往关乎着人类衰弱,数字医学正踊跃推动着医疗行业改革的步调,医疗人工智能适逢其时,撑持着丰盛的衰弱医疗利用,造福人类生命衰弱。在医学影像和病理图像智能剖析畛域,人工智能也有着广泛应用。人工智能在医学影像中的利用,其作用大体上可分为两个层面:一是加强成像成果,包含摄影和图像处理,提供更加可能诊断疾病的影像;二是剖析诊断,利用人工智能技术对影像进行剖析,从而给出诊断论断。简略来说,人工智能可赋能医学影像诊断,承当分类检出工作,进步诊断的效率和精准度,越来越多地帮忙医生欠缺临床决策中的暗藏见解,缩小医生的重复劳动,提供具备附加值的工作,将患者与资源分割起来进行全面治理,缓解看病难的问题,并从以前无法访问的非结构化数据资产中提取有意义的数据,进而进步综合医疗程度。医学成像数据是对于患者的最丰盛的信息起源之一,并且通常是最简单的信息之一。整顿并解读这些海量图像数据也是一项挑战,稳固牢靠的存储管理和服务系统对人工智能赋能医学图形影像解决和利用至关重要。 北邮 AI 医学图形图像钻研平台需要剖析本我的项目为人工智能学院医学图形图像钻研建设一套人工智能钻研平台,次要用于反对人工智能医学影像解决、智能医学图像了解、医学影像剖析等方面的科学研究工作。 智能医学平台数据存储的次要特点包含: 须要承载的文件量大,增速快,现有数据量在数百 TB 且数据以 TB 级 增长。海量的文件数量及快速增长驱使存储系统领有海量文件存储能力和弱小的扩大能力;大小文件混合场景,智能医学图形图像零碎中,蕴含了诸多类型的数据,大文件(医学影像、图片等)和小文件(形容信息、文本等)混合场景。对于存储系统来说须要兼顾大文件读写性能-带宽和小文件读写性能-IOPS;数据存量大、增量快的数据特点要求 AI 平台可能疾速地解决数据,同时,存储作为 AI 平台最重要组成部须要有足够高的性能,满足数据处理要求;每次运行 AI 训练任务,波及大量数据读写及运算,运行工夫较长。长时间运行的工作对于存储的稳定性提出了极高的要求,须要领有稳固的数据服务能力和稳固的零碎状态;原有的存储形式不能很好地满足科研工作的需要,次要体现在以下几个方面: 在整体架构方面,目前的存储形式是应用各个计算节点的本地硬盘来存储数据,这样带来了多方面的问题。例如,通过共享本地硬盘的形式可能反对的训练客户端十分无限,在这种存储形式中,本地硬盘的性能成为瓶颈,影响训练效率;其次,因为数据都寄存在独立的硬盘中,存在数据孤岛问题,节点与节点之间无奈实现数据共享,数据须要在节点间重复拷贝,浪费时间及存储空间;在性能方面,本地硬盘的性能难以满足高性能,海量文件的人工智能场景的存储需要,影响零碎效率。人工智能平台会解决海量数据,就须要存储系统可能高性能地提供待处理数据,同时 200Gb Infiniband 网络在 AI/HPC 场景中曾经遍及,存储系统必须能反对高速网络;在可扩展性方面,现有的存储形式不能很好的撑持海量的数据存储需要,也难以跟上数据激增的步调,平台的可扩展性也受限;YRCloudFile 构建国家级钻研平台建设为建设先进全面的科研模式,该院钻研平台抉择与焱融科技达成此次单干,共建高效的国家级钻研平台,为科研工作长足发展奠定根底。该人工智能学院过采纳焱融 YRCloudFle 分布式存储集群晋升 AI 平台整体效率,这带来了空谷传声的成果:新建的人工智能平台由计算集群,200Gb Infiniband 网络及 3 台焱融 YRCloudFile 分布式存储节点组成。在计算集群上运行医学解决剖析利用,通过 200Gb Infiniband 网络连接存储系统。业务平台建设计划架构图 焱融科技所提供的存储解决方案,该钻研平台建起大规模高速并行可扩大存储的数据平台,满足了根底钻研须要的同时,有了更多性能方面的晋升。 正当调配高效利用 采纳焱融分布式文件存储 YRCloudFile 反对目录配额治理和用户/组配额治理,应用一套存储集群满足不同用户的数据存储需要,多用户之间共享存储空间,实现了存储资源的正当调配和高效利用。采纳目录配额性能为不同用户设置独立的应用空间大小,防止了多个用户对于存储空间的抢占问题,实现了存储空间的正当调配;通过设置 QoS 性能解决了存储性能抢占问题,保障不同用户的不同业务获取正当的存储性能。 高性能线性扩大 存储集群通过 200Gb Infiniband 与前端计算节点相连,该平台具备了高性能的存储服务。焱融分布式文件存储 YRCloudFile 可将多台存储服务器上硬盘的读写能力聚合造成聚合带宽,搭建通用 X86 服务器,实现软硬件解耦,可按需部署,灵便扩大,使存储系统总体性能呈线性增长。实验室后续可通过减少服务器的形式,晋升整个存储系统的容量及性能。 海量文件反对 医学影像图片业务蕴含大量文件,这些文件既有大文件,如图片、图像等,也有海量小文件,如文本文件、形容信息文件等。作为数据的核心层,焱融分布式文件存储 YRCloudFile 具备海量结构化和非结构化数据管理能力,海量小文件操作和大文件解决的能力,深度优化的元数据服务提供了卓越的海量数据存储和拜访能力。不同科研人员可依据业务需要采纳相应存储接口对接到计算平台,YRCloudFile 所具备的大集群资源管理性能 QoS、配额治理等服务,可能更好地晋升整体存储服务能力。 北邮 AI 医学图形图像钻研平台采纳 YRCloudFile 提供的解决方案,打造了一套高性能、高可用、高扩展性的 IT 存储基础设施,在晋升海量文件数据存储能力的同时,智能医学平台也实现了全生命周期的数据管理能力,在保障百亿级文件操作性能晋升的根底上,全面晋升了数据管理效力,满足了钻研平台高并发拜访数据、数据共享平安及数据可扩大能力的需要,为钻研平台技术疾速落地提供了要害的存储撑持。北邮智能医学平台是学校增强新型交叉学科建设、助推“脑认知与智能医学”科研学术程度进步和推动医学迷信提高、促成人类衰弱倒退的重要依靠。 ...

June 13, 2023 · 1 min · jiezi

关于高性能:高性能网络-SIG-月度动态长期投入得到业界认可新增一位-virtio-reviewer

高性能网络 SIG(Special Interest Group) :在云计算时代,软硬件高速倒退,云原生、微服务等新的利用状态衰亡,让更多的数据在过程之间流动,而网络则成为了这些数据流的载体,在整个云时代扮演着前所未有的重要角色。在这个万物互联的时代,云上的网络通信效率对各种服务至关重要,高性能网络趣味组致力于利用 XDP、RDMA、VIRTIO 等新高效通信技术,联合软硬件一体化的思维,打造高性能网络协议栈,晋升云计算时代数据中心利用的网络的性能. 01 本月 SIG 整体停顿本月高性能网络 SIG 的次要工作聚焦在 Anolis OS 内核网络、SMC 和 virtio 上。 本月要害停顿: SIG 成员 Xuan Zhuo 成为上游 Linux kernel 社区 virtio core/virtio-net 子系统的 reviewer。Xuan Zhuo 过来三年在 virtio 社区的投入失去了宽泛的认可。SIG 本月实现了上游 virtio-net 对 XDP socket 零拷贝的反对,能够大幅晋升 virtio 下 XDP socket 的发包性能。该个性在龙蜥的 ANCK 内核上曾经反对了一年多的工夫,当初,咱们将该个性奉献到 Linux 上游社区,目前社区已实现 virtio-net XDP 重构局部的 review,预计 5.8 窗口期后合入。02 ANCK 内核网络本月网络方向新增安全漏洞修复:CVE-2023-1074 (SCTP 相干)。 03 高性能网络协议栈 SMC本月高性能网络 SIG 在 SMC 畛域的工作,次要聚焦在推动本机高性能通信,以及基于 eBPF 的策略替换两个计划在 Linux 上游社区的探讨。 ...

May 11, 2023 · 2 min · jiezi

关于高性能:性能最大提升60阿里云第八代企业级实例ECS-g8i正式上线

3月24日,阿里云发表新一代企业级弹性计算实例规格族ECS g8i正式上线,具备超高性能、全方位平安防护两大特色劣势。 从要害性能参数上看,g8i实例搭载了最新第四代英特尔® 至强®可扩大处理器(代号Sapphire Rapids,SPR),全核睿频p0n达到3.2GHz,相比上一代实例,整机核密度晋升50%,性能最大晋升60%以上。采纳CIPU+飞天的技术架构,网络标配阿里云自研eRDMA大规模减速能力,延时最低8微秒;存储方面全面搭载NVMe,反对共享盘,存储提早低至百微秒。同时,g8i反对可信计算与加密计算等个性,默认内存加密(TME),并在寰球范畴率先反对TDX秘密虚拟机能力。 阿里云弹性计算产品线负责人张献涛示意,阿里云第八代企业级实例g8i的正式上线,标记着阿里云自研的CIPU架构及其最新个性eRDMA能力全面开始商业化,将大幅晋升数据处理效率。阿里云CIPU+飞天的技术架构与第四代英特尔® 至强®可扩大处理器强强联合下,g8i规格族性能晋升了60%,并进行秘密虚拟机能力TDX在云上的首次实际,置信在单方的继续严密单干之下,将会给更多各行业的客户带来更具性价比的技术红利。 残缺内容请点击下方链接查看:https://developer.aliyun.com/article/1180147 版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

April 24, 2023 · 1 min · jiezi

关于高性能:高性能存储SIG月度动态ANCK-ublk完成POC测试EROFS优化xattr元数据开销

高性能存储技术 SIG(Special Interest Group)指标:高性能存储技术趣味组致力于存储栈性能开掘,以后次要聚焦内核 io_uring 技术优化异步 IO 性能,应用长久化内存晋升业务单老本性能,容器场景存储技术优化等课题。冀望通过社区平台,打造规范的高性能存储技术软件栈,推动软硬件协同倒退。 01 本月 SIG 整体停顿本月合入 Anolis 主线 PR 26 个,蕴含多个重要组件的更新。erofs 反对精简的 long xattr name prefixes,优化 overlayfs 场景 xattr 元数据开销。ANCK 5.10 ublk 已实现 POC 测试,相比 tcmu 时延优化 1 倍。io_uring asio 协程优化计划曾经确定,预计性能优化 10%。DSMS 治理平台的开发根本实现,dsms-storage 适配 Anolis 23 进行中。感激中兴的同学提交了多个 bugfix。 02 我的项目具体停顿1、Anolis OSext4:修复 ext4_xattr_delete_inode hang(PR1362) xfs:xfs_qm 清理(PR1326),修复 xfs_sysfs_init 内存泄露(PR1332/PR1334),移除 xfs_rename 中不正确的 ASSERT(PR1351),修复 force shutdown UAF(PR1376) fuse:修复 fuse flush/resend 接口 bug(PR1302)nfs:修复 RECLAIM_COMPLETE EACCES 问题(PR1324/PR1325),修复 slot 调配失败的内存泄露(PR1346/PR1347),修复遍历 grace_list 短少锁爱护问题(PR1350),修复参数解析空指针(PR1370),解决 CREATE_SESSION NFS4ERR_NOSPC(PR1368/PR1360)misc:修复 hugetlbfs_parse_param 空指针(PR1352),修复 configfs_create_dir 内存泄露(PR1357),修复 nbd_start_device_ioctl hang(PR1356),修复 rbd_sysfs_init() 内存泄露(PR1372/PR1373),修复 md_cluster unlock_all_bitmaps 野指针(PR1367),修复 nvme_alloc_admin_tags 空指针(PR1405)vfio:Clear the caps->buf to NULL after free(PR1422/1427),修复 drbd_create_device UAF(PR1251)VFS:修复 ltp/openat04(PR1489) ...

April 17, 2023 · 2 min · jiezi

关于高性能:焱融科技荣获爱分析信创产品及服务创新奖

近日,“2023爱剖析·信创产品及服务创新奖”评选活动落下帷幕。流动伊始,各行业企业及科技公司积极参与,通过申报、初评、调研、终评多轮角逐,焱融科技胜利获评,入选具备参考价值的信创实际翻新案例。此次评选活动旨在探讨和总结目前企业数据智能实际中的翻新案例,为行业提供有参考价值和学习价值的实践经验,帮忙企业更无效地实现信创替换降级。 作为当今局势下我国经济倒退的新动能,信创产业是我国企业实现数字化转型、放弃外围竞争力的驱动引擎。构建安全可靠的信创产业体系,能无效解决核心技术和关键环节的“卡脖子”问题,保障我国信息技术平安、稳固、有序倒退,铸牢我国信息基础设施的平安之基。存储是企业 IT 基础架构的外围,是影响信息安全的要害组件,存储的性能和可靠性对企业发展要害业务和保障数据安全至关重要。分布式存储在实现架构降级的同时可实现信创转型,分布式存储可打消传统控制器架构瓶颈,晋升零碎并发性能和资源利用率;在信创技术栈,分布式的架构能够局部补救国产 CPU 性能有余的问题。 焱融科技作为一家软件定义存储产品和解决方案的国家高新技术企业,实现中关村高新、“专精特新”等企业认证。在分布式存储等关键技术上领有自主知识产权,焱融科技以分布式存储技术为外围,致力于打造面向云 +AI 时代的数据存储基石。其自主研发的分布式文件存储产品 YRCloudFile 实用于人工智能、智能汽车、国家实验室、教科研、政企、金融量化、能源、制作、生命科学、基因剖析、医疗影像、等场景。焱融科技全面适配国产化及周边生态,实现与多家信创平台 X86、海光、鲲鹏、统信等芯片及操作系统的兼容性互认证,推动信创产业倒退及数据安全可控。焱融分布式文件存储 YRCloudFile 可部署在大规模虚拟化、公有云、容器等环境中,反对多种计算平台,提供高可用、高性能、易扩大、易保护的存储解决方案,焱融分布式文件存储具备以下产品劣势: 焱融科技将继续在数据存储畛域深耕细作,帮忙企业构建高效、便捷、平安的基础设施,为金融数字化转型打造牢靠存储底座,为促成存储技术倒退、存储国产化贡献力量。

March 31, 2023 · 1 min · jiezi

关于高性能:YRCloudFile-V6100-功能新增对-NVIDIA-GPUDirect-与回收站的支持

近日,焱融科技公布分布式文件存储产品 YRCloudFile V6.10.0 版本。在该版本中,YRCloudFile 首次反对了 NVIDIA GPUDirect Storage(GDS)、新增回收站、数据加载热层清理等产品性能,继续优化并大幅晋升作为企业级存储产品的性能和可用性,进一步晋升用户应用体验。 YRCloudFile 是焱融科技基于软件定义存储自主研发的独立的混合云文件存储系统,基于灵便的 SDS 架构, 可提供 POSIX、NFS、SMB/CIFS 等丰盛的文件服务,不仅能够广泛应用于企业级文件共享,大容量数据存储、大数据等通用场景,还能更成熟的利用于智能汽车、多模态 AI 、HPC 高性能计算、生物信息、GIS 等高性能计算利用场景。 在 6.10.0 版本中,YRCloudFile 进行了以下重要更新: 国内首发反对 NVIDIA GPUDirect Storage(GDS): 焱融技术团队历时 6 个月的工夫实现对 NVIDIA GPUDirect Storage(GDS)的适配开发,实现以间接内存的存取形式,将数据传输至 GPU 内存上,显著升高 I/O 提早,晋升数据带宽。 反对回收站性能:通过 YRCloudFile 回收站性能可复原文件数据和相干元数据信息,防止因为误删除操作造成的文件数据失落问题,进一步晋升存储系统的可靠性及数据的安全性。 反对数据加载热层数据清理性能:数据加载反对了热层清理性能,用户通过对文件的冷热策略定义的形式来开释文件系统空间,而存储在文件系统 YRCloudFile 的元数据仍将保留,下次读取数据时,文件存储会从对象存储中主动拉取。同时,数据加载配额治理 (Quota) 解决了加载大量对象存储数据到文件系统内所造成的空间占用问题,减少对 Dataload 目录的配额设置反对。 元数据性能优化:针对 AI 训练中海量小文件读写场景,实现了客户端的轻量级只读 Open, 升高了元数据的拜访操作。可同时保障在文件系统语义的前提下,将局部逻辑 offload 到客户端,大幅升高元数据服务的压力,使集群的元数据性能失去很大的晋升。 功能丰富有温度 用户操作便捷更安心无需放心误删操作,回收站性能一键找回YRCloudFile 提供残缺的回收站性能,当误删除文件系统中的文件后,可通过回收站复原这些文件的数据与元数据信息。回收站性能默认处于开启状态,当相应的文件被系统命令或者程序行为删除后,将以就近准则的形式主动进入相应的回收站,该操作只是挪动元数据,所以不会带来存储空间则增大的问题。当用户须要复原回收站的数据时,可依照文件删除工夫、门路进行定位、查找,疾速实现数据恢复操作。 数据加载热层清理让存储空间应用更高效该版本的数据加载性能反对热层清理性能,依据对文件的冷热策略定义(例如:超过肯定工夫并未被拜访的文件),可采纳定时调度或者立刻清理的形式来开释被占用的文件系统空间,而对应的文件用户仍然能够拜访。当下次读取数据时,文件存储主动从对象存储内进行数据加载,这使得文件存储 YRCloudFile 的空间能够高效的轮转应用,既能保障高性能的数据拜访,又能升高整体存储老本。当加载大量对象存储数据到文件系统造成的的空间占用问题,用户可通过数据加载配额治理(Quota) 减少对 Dataload 目录的配额设置反对。当 Quota 空配额耗尽时,则无奈写入新文件;当读取对象存储新文件时,零碎采纳 by-pass 形式间接从对象存储取得数据返回给业务层。 性能晋升 高性能计算与AI 交融场景不容错过国内首家反对 GPUDirect® 分布式文件存储NVIDIA GPUDirect Storage(GDS) 技术通过 DMA 引擎将硬盘数据间接写入 GPU 显存,这种以间接内存的存取形式,防止了内存 bounce buffers 所带来的额定数据拷贝,进步了存储和 GPU 之间数据挪动的效率,大幅晋升 GPU 载入大型数据集的速度。焱融科技 YRCloudFile 通过对 NVIDIA GPUDirect Storage(GDS)的反对,可能更好地治理数据门路,使数据在应用程序和存储之间通过更短、更无效的门路传输,使反对 GDS 的应用程序可能充沛开释 GPU 计算能力,为人工智能和机器学习(AI/ML)以及数据分析等业务减速。 ...

March 30, 2023 · 1 min · jiezi

关于高性能:DatenLord前沿技术分享-No18

达坦科技专一于打造新一代开源跨云存储平台DatenLord,致力于解决多云架构、多数据中心场景下异构存储、数据对立治理需要等问题,以满足不同行业客户对海量数据跨云、跨数据中心高性能拜访的需要。高性能RDMA网络协议栈是RDMA高性能网络的外围组成部分之一,它提供了反对RDMA技术的网络协议和驱动程序。在本周的前沿科技分享中,咱们邀请到了湖南大学信息科学与工程学院的陈果传授来给咱们分享高性能RDMA网络协议栈的话题。 1、演讲题目高性能RDMA网络协议栈 2、演讲工夫2023年2月26日上午10:30 3、演讲人陈果,湖南大学信息科学与工程学院传授/博导,校园信息化办副主任,国家优青。博士毕业于清华大学计算机系,曾任微软亚洲研究院网络组副研究员。长期从事高性能数据中心网络方面钻研,在相干学术刊物和会议发表论文40余篇,申请国内外专利10余项,研究成果利用于华为鲲鹏芯片、腾讯自研交换机、腾讯CDN网络和百度无线搜寻等。入选国家优青、湖南省优青、长沙市杰青等人才打算,获华为最佳技术单干传授、湖南省科技进步二等奖、全国高校计算机专业优秀教师、湖南省信息化教学比赛一等奖等多个科研和教学奖项。 4、介绍RDMA网络协议栈具备极高的接入速度和极低的解决延时,已成为目前数据中心网络、超算网络等高性能网络的首选。然而, RDMA始终难以在大规模网络中部署。其面临的最大难点是,为保障解决性能,协定栈解决所需的中间状态须压缩至很小的高速缓存中,因而只能实现非常简略的协定性能,无奈应答大规模网络中丢包、多路径等简单状况。 针对此问题,报告人提出了一系列高性能、低开销的RDMA协定栈架构与技术,将RDMA中多路径拥塞管制、抉择重传位图和牢靠传输等重要性能的状态开销缩减为与并发流数目无关的常数级别,冲破RDMA在大规模高性能网络中部署的难题,其中局部技术已利用于华为鲲鹏芯片中。本次报告将介绍报告人近年来发表在NSDI、ICNP、ToN等会议和期刊上的一系列高性能RDMA网络协议栈方面的钻研工作。 5、直播预约欢迎您关注微信公众号:达坦科技DatenLord预约直播,或者登陆腾讯会议观看直播: 会议号:955-6910-3992

February 24, 2023 · 1 min · jiezi

关于高性能:高性能网络SIG月度动态virtio新设备进入virtio规范smc新特性IPC性能比tcp提升88-龙蜥SIG

高性能网络 SIG :在云计算时代,软硬件高速倒退,云原生、微服务等新的利用状态衰亡,让更多的数据在过程之间流动,而网络则成为了这些数据流的载体,在整个云时代扮演者前所未有的重要角色。在这个万物互联的时代,云上的网络通信效率对各种服务至关重要,高性能网络趣味组致力于利用 XDP、RDMA、VIRTIO 等新高效通信技术,联合软硬件一体化的思维,打造高性能网络协议栈,晋升云计算时代数据中心利用的网络的性能。 01 本月 SIG 整体停顿12 月高性能网络 SIG 的次要工作聚焦在 Anolis OS 通用内核网络、SMC 和 virtio 上。以下为要害停顿: 龙蜥社区高性能网络 SIG 提出的 virtio 设施:virtio-ism 的 spec 提交到 virtio 社区,相应的设施 ID 通过 virtio TC 的投票曾经进入 virtio 标准。龙蜥社区高性能网络 SIG 提出的 SMC loopback 设施的反对的 RFC 提交到 linux 社区探讨。ANCK-5.10 行将公布 013 版本,SMC 做了大量的优化和修复。02 Anolis OS问题修复12 月 ANCK 网络方向共计修复 33 个 CVE(蕴含一个高危 CVE-2022-4378),笼罩 tcp/netfilter/ip/tc/vsock/wifi/bluetooth/can 等模块,CVE 列表:CVE-2022-42895、CVE-2022-3435、CVE-2022-3633、CVE-2022-3535、CVE-2022-0812、CVE-2022-39190、CVE-2022-42719、CVE-2022-1015、CVE-2022-42895、CVE-2021-4203、CVE-2022-1204、CVE-2022-1012、CVE-2021-33135、CVE-2022-1012、CVE-2022-1966、CVE-2022-1966、CVE-2022-1679、CVE-2022-3028、CVE-2022-3028、CVE-2022-2663、CVE-2022-3567、CVE-2022-3586、CVE-2022-41674、CVE-2022-42722、CVE-2022-42721、CVE-2022-42720、CVE-2022-3566、CVE-2022-3521, CVE-2022-3524、CVE-2022-3435、CVE-2022-3564、CVE-2022-3625、 CVE-2022-4378。 性能加强PR908 5.10 内核 ipvs 反对通过 run_estimation sysctl 敞开 estimation。03 SMC版本公布12 月 SMC 最新稳定版将随着 ANCK 5.10-013 公布。本次公布的版本将包含如下更新: ...

January 11, 2023 · 2 min · jiezi

关于高性能:高性能存储SIG月度动态DSMS开始适配Anolis-OS将在ANCK-510中支持ublk-龙蜥-SIG

高性能存储技术 SIG 指标:高性能存储技术趣味组致力于存储栈性能开掘,以后次要聚焦内核 io_uring 技术优化异步 IO 性能,应用长久化内存晋升业务单老本性能,容器场景存储技术优化等课题。冀望通过社区平台,打造规范的高性能存储技术软件栈,推动软硬件协同倒退。 01 本月 SIG 整体停顿本月共合入 Anolis 主线 PR 16 个,蕴含多个次要组件的个性加强、CVE 修复,以及 bugfix 等。 继 11 月在 ANCK 5.10 加强 erofs over fscache,反对上游新个性 shared domain 和 failover 后,12 月在 ANCK 4.19 也反对这两个新个性,为 ANCK 4.19 erofs over fscache 镜像减速计划上生产环境铺平了路线。 xfs inode extent-to-btree 转换失败问题社区主线计划仍在探讨中,xfstests 用例更新已合入主线。 DSMS 开始适配 Anolis OS 的适配工作,我的项目文档同步开始更新至 SIG。 02 我的项目具体停顿1、Anolis OScve:CVE-2022-33981 / CVE-2022-1836(PR552) erofs:misc bug fixes for RAFS mode(PR967),cachefiles: add missing lock protection when polling(PR1004),support shared domain feature on ANCK 4.19(PR974),support failover feature on ANCK 4.19(PR975),cachefiles: fix potential NULL in error path(PR1023) ...

January 6, 2023 · 2 min · jiezi

关于高性能:存储性能加速引擎之预读

程序预读(prefetch,在Linux中也称为预读,read ahead)是一种用于晋升程序读性能的技术,用于放大存储设备和应用程序之间微小的效率差距。Linux内核在通用预读框架中执行程序文件预读,它被动拦挡VFS层中的文件读取申请,并将程序的申请转换为异步预读申请,为行将到来的申请引入数据块,并在大块中进行。 I/O预读背景带宽和提早是I/O性能的两个次要衡量标准。对于这两个规范,在磁盘、内存和处理器之间存在着微小的性能差距。例如,当今的DDR5内存的实践带宽通常为40GB/s以上,响应工夫为纳秒级,而一个希捷(R) 7200转SATA磁盘的最大继续传输速率为200MB/s,均匀寻道工夫为5ms。两者之间存在的性能差距,带宽相差数百倍,提早相差10^7倍。 I/O提早是影响磁盘I/O性能的一个次要因素,能够用一个简略的I/O模型来近似。典型的磁盘I/O有两个步骤:首先,磁头挪动到数据轨道,期待数据扇区在其下旋转;其次,开始数据读取和传输。相应的有两个操作工夫:均匀拜访工夫,典型值为8ms;数据传输工夫,大抵等于I/O大小和磁盘继续传输速率的乘积,对于目前的一般磁盘(HDD),均匀传输速率为200MB/s。 在一个残缺的I/O周期中,只有数据传输工夫能力真正利用磁盘数据通道。I/O大小越大,在数据传输上破费的工夫就越多,相对来说,在搜寻上节约的工夫就越少,因而咱们能够取得更多的磁盘利用率和I/O带宽。下图反映了上述磁盘I/O模型和代表性参数值的相关性。I/O预读的次要目标是将图中磁盘的工作点从左向右挪动,从而取得更好的I/O带宽。 应用较大的I/O大小能够更好地利用磁盘 随着数字信息的激增,提前读算法依然在持续施展重要作用。固态磁盘极大地缩小了耗时的寻道工夫,然而依然存在不小的拜访提早。特地是SSD存储器基本上是由许多并行操作的芯片组成,较大的预读I/O将可能利用并行芯片的劣势。从SSD存储取得齐全性能所需的最佳I/O大小与旋转介质不同,并且因设施而异。因而,即便是在SSD上,I/O预读也很要害。 总之,有程序拜访模式的中央,就有I/O预读的市场。无论是基于机械磁盘还是固态磁盘。 I/O优化和预读从利用角度,目前业界有四种根本的I/O优化策略: 防止从存储设备上IO。最好的抉择是完全避免或尽可能减少存储介质拜访频率。这能够通过文件内存缓存来实现。预读擅长于将小的读申请转换为大的读申请,这无效地缩小了存储介质拜访的数量,从而升高了昂扬的查找老本。具体的例子是家喻户晓的Linux VFS(虚构文件系统)挂载选项noatime和relatime,用于打消由mtime更新触发的不必要的向存储设备的写操作。 程序化。程序拜访能反对程序预读并最大化磁盘性能利用率。对于并发程序拜访,预读在将交织的小I/O聚合为大I/O方面起着至关重要的作用。对于非程序拜访,通过应用智能磁盘布局治理、告诉式预读、I/O排队和调度等技术,将磁盘寻址提早最小化。举几个通过程序化进行性能优化的例子:SCSI磁盘的TCQ(标记命令队列)和SATA磁盘的NCQ(本机命令队列);ext4/xfs的提早调配和预调配;xfs中的回写集群等。 异步化。异步拜访通过流水线化处理器和磁盘操作,暗藏应用程序的I/O提早的形式来进步I/O效率。AIO、非阻塞I/O、回写和预读是异步I/O的常用工具。 并行化。聚合多个磁盘的容量和带宽可晋升整体IO性能曾经是分布式存储的共识。在传统的RAID层之外,以zfs和btrfs为例的新兴文件系统能够本人治理大型磁盘池。另一方面,在SSD外部应用了设施级并发解决。例如,英特尔在其SATA固态硬盘中开拓了10个并行的NAND闪存通道,可提供高达500MB/s的读取带宽和50000以上的 IOPS。并发I/O申请和并行数据传输是上述并行零碎的I/O吞吐量的要害。被动预读在这个畛域中扮演着重要的角色:它们通常须要大型的异步预读I/O来填充并行数据通道。 预读有助于实现I/O异步和并行 显然,预读在四种I/O优化策略中都扮演着重要的角色。预读能够为应用程序、存储设备和存储池,甚至处理器资源带来性能改善。通过屏蔽较高的I/O提早,应用程序能够运行得更快更晦涩。大块I/O能够更好地利用磁盘,能够更好地并行化,也有助于摊薄整个I/O门路的解决开销。 预读的根本办法预读算法能够是预测式的,也能够是利用被动告诉式的。预测式算法试图基于过来的I/O预测将来将被拜访的I/O块,自动自发地执行预读决策,对下层利用是通明的,这种形式对算法的要求较高,存在命中率的问题。最胜利的一种做法是程序预读,这始终是操作系统的规范实际。新型的预测式预读能够基于灵便的AI算法或统计,晋升预读数据的命中率。 利用被动告诉式预读,应用来自各个应用程序对于其将来I/O操作的提醒,提醒能够由应用程序显式地管制。 缓存是另一种普遍存在的性能优化技术。共享预读内存和缓存内存是一种常见的做法,这为预读和缓存之间的交互关上了大门。 预读的设计衡量预读大小对I/O性能有很大影响,被认为是次要的预读参数。在确定预读大小值时,必须在吞吐量和提早之间进行衡量。个别的领导准则是:预读的大小应该足够大,以提供良好的I/O吞吐量,但同时也要避免预读块过大,从而防止不必要的过长的I/O提早。 不同的存储设备、磁盘阵列配置和工作负载具备不同的最佳预读IO大小。某些应用程序(如对I/O提早不敏感),能够平安地应用较大的预读大小;其余利用可能对I/O提早敏感,这时应该应用更激进的预读I/O大小。 除了吞吐量和提早之间的衡量之外,预读命中率是另一个常见的设计思考因素。为了放弃较高的预读命中率,须要应用自适应预读大小。这是因为,即便咱们确信应用程序正在进行程序读取,咱们也无奈预知程序读操作还会继续多久。例如,应用程序可能从头到尾读取一整个文件,而另一个应用程序只拜访这个文件中的前两个page。 侥幸的是,常见的I/O行为大多是能够推断的。首先,行将要读取的page数(不思考文件完结的状况)和已拜访的page数通常是正相干的。其次,读取的大小越大,反复的可能性就越大。因为较大的预读大小意味着研发人员要对预期的长时间预读进行优化。依据以上两条教训规定,能够预计以后拜访模式反复的可能性,并据此计算自适应预读大小。 进步预读命中率是预读算法设计的一个次要指标。低命中率意味着内存和磁盘I/O资源的节约,这样节约是昂扬和不可承受的。传统的预读算法偏向于只对严格的程序读取进行预读。它们对预读大小采纳激进策略,并采纳程序检测,以寻求较高的预读命中率。 然而,随着计算机硬件的疾速倒退,咱们也面临着新的束缚和要求。内存和磁盘的带宽和容量都有了很大的进步,但磁盘拜访工夫依然很慢,并且越来越成为I/O瓶颈。因而,预读命中的益处就减少了,它减少了预读的重要性,意味着底层存储应该更被动地进行预读。 因而,即便就义肯定的预读命中率,它也能够进步总体I/O性能。工作负载的预读命中率取决于IO模式识别和这种特定模式运行时长评估的准确性。 YRCloudFile Linux客户端预读YRCloudFile Linux客户端预读,对接了Linux内核预读机制,专门针对程序读的性能进行优化。 下图为用FIO测试工具,对小文件程序读、大文件程序读场景进行测试,在Linux客户端预读开启和敞开状况下,不同内核版本的不同性能体现。 预读对4K/1M程序读性能的影响 从理论测试数据看,YRCloudFile Linux客户端预读性能开启与否,在不同内核版本的下,程序读性能晋升2.5-20倍不等。 YRCloudFile Linux客户端预读机制很好地解决了文件程序读速度慢、拜访提早高的问题,帮忙AI利用,影视内容制作等利用轻松应答海量文件程序读拜访的性能挑战。 不可能有一种技术满足所有的需要,业务软件是单线程还是多线程、IO特点是一次写屡次读还是一直追加写、是程序读还是随机读等等。焱融技术团队通过一直的与客户的交换、碰撞,对不同场景,不同类型的利用进行剖析,一直推出新的性能,让YRCloudFile更趋于成熟,帮忙用户成就大数据与人工智能时代的企业外围竞争力。 参考资料1.https://bootlin.com/pub/readahead/doc/ols2007-readahead-paper.pdf\2.https://engineering.purdue.edu/~ychu/publications/tc07_pref.pdf\3.https://pdfs.semanticscholar.org

August 11, 2021 · 1 min · jiezi

关于高性能:EDA最强攻略如何为EDA选择存储

当今数字芯片技术飞速发展,数字半导体芯片曾经渗透到社会生存的各个领域,从生产电子产品、工业自动化设施到航天技术都能看到半导体芯片技术的身影。国家在芯片技术上的投入和器重水平也晋升到策略层面,芯片设计制作正在成为新一代的国之重器。 01 EDA是什么?EDA 是芯片之母,是芯片产业皇冠上的明珠,是集成电路设计最上游、最高端的产业。EDA(Electronic Design Automation)是电子设计自动化的简称,EDA的倒退经验了CAD、CAE等阶段,随着集成电路技术倒退,EDA 越来越被业界予以“芯片设计软件工具”的代名词。2018 年寰球集成电路产值近 5 千亿美金,中国集成电路进口金额超 3 千亿美金,EDA 是集成电路产业产能性能源头,从仿真、综合到幅员,从前端到后端,从模仿到数字再到混合设计,以及前面的工艺制作等,EDA 软件工具涵盖了 IC 设计、布线、验证和仿真等所有方面,是集成电路产业的“摇篮”。 利用EDA工具,工程师将芯片的电路设计、性能剖析、设计出IC幅员的整个过程交由计算机主动解决实现。在没有EDA工具之前,设计电路要依附手工,但对于大规模集成电路有上亿晶体管的设计用手工几乎是不可能的。能够说有了EDA工具,才有了超大规模集成电路设计的可能。 硬件描述语言(HDL-Hardware Description Language)是一种用于设计硬件电子系统的计算机高级语言,就是用软件编程的形式来形容简单电子系统的逻辑性能、电路构造和连贯模式。硬件描述语言是EDA技术的重要组成部分,是EDA设计开发中很重要的软件工具。 目前国内外的EDA软件次要供应商包含Synopsys、Cadencen、Mentor Graphics、华大九天、芯愿景、芯禾科技等,EDA利用涵盖了通用、专用芯片的设计制作等场景。 02 EDA工作流程和IO特点EDA典型的工作流程包含了以下几个阶段: —前端设计阶段(逻辑设计) 设计规范性能验证合成逻辑验证—后端设计阶段(物理设计) 布局和布线动态时序剖析物理验证—生产制作 流片这些阶段相互作用以造成EDA的数字设计流程: 在前端设计阶段,工程师通过将VHDL等源文件编译为芯片模型来实现芯片设计,而后通过在大型计算集群中散发工作来验证芯片设计。调度程序将仿真和模仿工作散发到不同的计算节点上,这些计算节点通过共享文件系统来拜访后端的芯片模型。在整个前端设计过程中,工程师须要不断改进设计,整个过程须要屡次迭代,因而,前端设计阶段会生成大量仿真工作。创立、调度和执行build和仿真作业的效率,决定了将芯片推向市场所需的工夫。 当大量作业并行运行时,会产生大量IO负载,EDA应用程序须要读取并编译数百万个小的源文件,用以构建和模仿芯片设计。后端的共享文件存储管理各种芯片设计目录和文件,以便不同的用户、脚本和应用程序能够拜访数据。 在前端验证阶段,数据拜访模式往往是随机的,并带有大量小文件。前端工作负载须要极高的并发性,从而满足大量作业并行拜访的须要,这些作业将生成大量随机拜访的IO。此外,因为随同着大量小文件拜访,这个阶段对元数据拜访性能是极大的考验。 从一些公开的数据上看,半导体芯片设计过程中,对元数据调用(包含GETATTR,ACCESS和LOOKUP)占所有调用的85%以上,而“读取”和“写入”不到15%。对于传统NAS阵列或单MDS的分布式文件存储架构而言,将会面临较大的挑战。 在后端设计和验证阶段,数据拜访模式将次要以程序拜访为主。后端设计阶段的工作负载往往由较少数量的工作组成,这些工作具备程序的IO拜访特点,并且运行工夫较长。在后端设计阶段的工作工作,次要考验后端文件系统的并行拜访带宽。 联合前端设计和后端设计两个阶段的IO拜访特点来看,EDA芯片设计和仿真过程中,对元数据和数据,小文件IOPS及大文件程序拜访带宽,都有极高的要求。这一过程与大型的程序(如Linux内核)并行编译过程中产生的IO特点类似。 芯片设计阶段波及的所有作业的输入都可能产生TB级的数据。只管有些数据是临时性(如时序仿真等)的,但这些数据依然须要最高级别的存储性能,能力对芯片设计整个流程进行保障。 半导体行业巨头Intel公布的一份报告显示,在过来10年,Intel用于半导体设计和制作的外部基础设施投入中,计算和存储的CAGR达到30%以上,并且没有缩小任何IDC站点。 只管英特尔在EDA场景中可能独占鳌头,但咱们从行业数据中能够看到,绝大多数的半导体设计企业对基础设施的投入年增长率都超过20%。 03 如何满足EDA场景的存储需要文件存储主导 在存储系统中,EDA工作流都是将大量的数据通过文件系统进行共享和拜访,并且在零碎中生成深层的目录构造,使得文件系统在EDA存储系统中占主导地位。 YRCloudFile高性能分布式文件存储,具备卓越的性能、灵便的程度扩展性、海量小文件存储能力等个性,能够满足EDA利用中大规模计算集群以文件形式并行拜访数据的需要。 超高并发性能 大多数EDA工作流须要极高的并发性,YRCloudFile可能满足数千高性能Linux计算群集的并发要求,提供远高于规范NAS协定(NFS、SMB)的并发能力。 EDA工作负载中产生的大量元数据操作,能够通过YRCloudFile灵便扩大的元数据服务进行满足和匹配,解决了EDA负载对元数据性能的要求。 灵便弹性扩大 EDA工作负载在执行过程中,会产生TB级的数据或两头后果,YRCloudFile分布式文件系统采纳分布式架构,将所有磁盘进行对立治理,提供对立命名空间,反对容量和性能的程度扩大,可按需实现疾速扩容,满足EDA对大容量存储的需要。

August 2, 2021 · 1 min · jiezi

关于高性能:如果说数据是推动自动驾驶的原动力那么存储扮演什么角色

近年来,互联网、IT技术正在带动整个汽车产业迎来粗浅改革。在此之前,信息技术帮忙汽车行业实现了设计、供应链、营销等体系的数字化和互联网化。在传统汽车厂商进行数字化转型的同时,新能源汽车、车联网、主动驾驶等新技术衰亡,特斯拉、蔚来、现实、小鹏等新厂商涌入汽车制作行业,汽车行业竞争愈发强烈,十年内实现全自动或“无人驾驶”汽车,成为了传统汽车制造商、新兴汽车制造商、业余主动驾驶解决方案供应商独特抢夺的新的技术制高点。 旨在加强乘客、车辆和路线安全性的主动驾驶,对汽车设计和制作过程的IT基础设施(尤其是存储系统)提出了革命性的新要求。 01 主动驾驶数据处理流程主动驾驶是人工智能,尤其是视觉辨认及自动化在汽车制作及运行畛域的细分利用。主动驾驶与视觉辨认的数据处理流程有肯定水平的相似之处,都是通过对海量数据的收集、特征分析、训练、验证,最终造成一个高度精准的数据处理模型,用于应答理论路线中实时变动的路况信息,从而实现主动驾驶。 数据收集 AI外围算法是主动驾驶的发动机,数据是AI引擎最不可或缺的燃料。测试车辆上携带的摄像头、声纳、雷达、LIDAR、GPS以及更先进的传感器设施,能够捕捉大量包含视频、图像、天气信息等信息在内的原始非结构化数据。 Figure 1: 开发和验证主动驾驶的典型数据处理流程 模型训练和开发 数据准备就绪后,主动驾驶工程团队应用来自所有传感器、GPS、天气、路线、环境等多因素交融的数据,提取数据特色,并联合这些数据特色下的正确行为,通过深度学习和迭代,取得主动驾驶中的模型和参数,造成初步的主动驾驶模型。 验证和测验 工程师通过在软件环境、汽车理论硬件环境上构建充沛的测试用例,对主动驾驶模型进行全方位仿真和理论测试,以期涵盖所有可能的路面状况。并将电子管制单元ECU所做的判断和决策与测试司机实际操作进行比照,二者差别视为主动驾驶模型潜在的bug,进而对模型进行修改。 归档 通过最终验证后,工程团队将主动驾驶的测试数据移至低成本的归档存储中。归档数据必须满足法定的监管要求,这些已经应用的测试数据可能须要保留数十年,以防在召回的状况下,对数据进行从新验证和计算。 02 主动驾驶数据处理面临的挑战主动驾驶数据处理过程须要PB级的高性能存储。随着数据量的增长,传统存储架构的局限性和有余将被放大,越来越难以漠视。 爆炸性数据增长 因为安全性对主动驾驶零碎至关重要,因而主动驾驶对设计制作过程中所经验的测试数据量要求很高,随着主动驾驶水平的增高,所必须的测试数据需要会成倍增加。在汽车工程师协会(SAE)定义主动驾驶的六个级别中,SAE 2-3级通常要求测试车辆累计收集20万至100万km的实在路测数据,用于主动驾驶软件开发和验证。SAE 4级将须要200万+公里的数据,随着行业向SAE 5级(全自动驾驶汽车)倒退,这一数据需要将减少到约2.4亿公里。 采集、寄存并剖析这么多里程的传感器数据,对于主动驾驶中的存储系统而言是微小的挑战。以一个典型的SAE 2级主动驾驶我的项目为例,以75km/h的平均速度收集20万km里程,将生成2,666个小时的数据,单个传感器须要大概3.8PB的存储空间,而主动驾驶测试车辆中须要有多个传感器。SAE 3级主动驾驶我的项目须要收集百万公里的数据,意味着传感器将生成19.3PB的原始数据。 大规模环境下的拜访性能 随着无人驾驶汽车向SAE更高级别倒退,存储的架构必须可能满足一直增长的性能需求。主动驾驶开发和验证零碎须要存储系统在确保存储容量能无缝扩大的同时,各个数据处理流程中在加载数据时,不存在加载速度瓶颈。 数据筹备阶段波及十分密集的数据预处理,用于读写原始视频数据和传感器二进制文件,这对存储系统提出了高带宽要求。而在训练过程中,AI训练须要解决海量的小文件(视频或图片),为了保障训练GPU处于满负荷运行的状态,存储系统须要提供足够的小文件拜访带宽和足够低的延时。此外,主动驾驶训练集群通常由几十甚至数百台GPU服务器组成,确保大规模的计算集群对数据的并发拜访晦涩,也是对存储系统的必要要求。 海量数据存储的总体老本 只管对主动驾驶数据保留的年限尚未造成国际标准,然而大多数汽车制造商要求主动驾驶数据必须保留数十年。如何高效、低成本地保留这些海量数据,同时保障下层利用无感知、高性能地拜访,是汽车制造厂商在存储架构面临的又一挑战。 03 如何应答主动驾驶数据存储挑战YRCloudFile是焱融科技面向云+ AI 时代的新型分布式存储产品,其卓越的性能、灵便的程度扩大能力能帮忙主动驾驶、人工智能等业务显著晋升效率;通过智能分层技术,使数据生命周期失去更精细化的主动治理,极大地升高数据存储老本。 YRCloudFile横向扩大架构非常适合主动驾驶开发和验证场景,可在一直扩大的单个命名空间中提供数百PB级的存储容量。YRCloudFile可通过10/40/100GbE或InfiniBand网络进行连贯和横向扩大。YRCloudFile可通过纯软件形式,部署在规范服务器上,缩小汽车制造商对传统存储厂商特定存储设备的依赖。 目前焱融科技已胜利与科大讯飞、依图等国内出名AI公司实现单干,并且在2020年获取了国内软件定义存储首个海内客户,实现了产品的国际化。

July 30, 2021 · 1 min · jiezi

关于高性能:CIOCTO必读-数字转型时代企业存储支出知多少

企业的CIO、CTO们除了关注业务撑持、技术演进之外,还有关怀一个永恒的话题:IT老本优化和投入产出比。对于这个话题,咱们最近在Gartner上读到一篇很有意思的报告,急不可待分享给大家《IT Key Metrics Data 2021 Infrastructure Measures — Storage Analysis》。 随着企业和组织进行数字化转型,IT老本治理将变得越来越重要,Gartner的这篇报告在2020年从寰球范畴内做了用户考察,蕴含了存储老本效率和存储反对人员的生产效率基准方面的均匀数字,这些调查结果能够作为CIO、CTO们思考老本治理时的一部分根据。考察的企业所治理的数据量散布如下图所示: Source:Gartner (2020)这些客户所应用的存储架构,横跨了不同的存储档次(包含DAS,网络存储,近线和离线存储)。报告所钻研的指标包含了老本效率和运维生产力的平均值,这些指标以存储的裸容量TB数为单位。 每TB存储裸容量的每年老本这个指标揭示了客户整体存储环境的绝对老本程度。在具体业务场景、SLA、存储利用率、企业内应用的整体存储计划以及整体存储管理策略不同时,这个老本程度有较大差别,CIO、CTO们应该依据本人的理论要求进行参考。 Source:Gartner (2020) 能够看到,在被考察企业内,大多数企业的每TB每年存储开销在416-1048美元,均值为652美元,环境规模越小,均匀开销越高(<3PB的均匀开销为1141美元,3-10PB的均匀开销为671美元,>10PB的均匀开销为484美元)。 企业在负责存储的全职工程师的均匀开销通过考察,企业在负责存储的全职工程师均匀开销为125美元/TB,该老本因工作地区、教训和专业知识而有所区别。大多数企业用于存储全职工程师的开销为每TB111-168美元,治理数据规模越大,用于存储工程师的每TB均匀收入越高,<3TB的环境均匀为117美元,3-10PB均匀为121美元,>10PB均匀为134美元。 Source:Gartner (2020) 存储全职工程师外包比例负责存储的企业内人员和外包工程师的比例为92:8。很多企业反馈,通过外包,能够放弃IT的灵活性和敏捷性。然而,如果企业没有造成很好的知识库、知识产权和流程治理,长期应用外包反而会减少老本,这也很好解释了企业内应用存储外包工程师的比例较低的起因。 Source:Gartner (2020) 每个全职的存储工程师治理的裸容量数量理解存储工程师治理数据量的均匀效率,对于建设“适合规模”的高效数据管理团队具备重要意义。存储工程师的管理效率与存储架构的复杂度、存储产品服务的反对有严密关系。 Source:Gartner (2020) 论断通过这篇报告,能够看到在企业外部,治理存储的人力老本还是十分高的,通过晋升存储工程师治理的数据规模,能够无效缩小数据管理团队的人力投入,这时候,存储软件和存储系统就起到要害的作用了。**在应用YRCloudFile的理论客户中,通过咱们的产品以及全面的服务反对,客户的单个存储工程师治理的数据量超过了30PB,这为客户升高总体的数据管理老本起到了十分大的作用。** 心愿这篇报告的解读能帮忙CIO、CTO们更好理解业界在数据存储上的投入和老本散布,进而无效晋升存储架构的投入和产出。

July 5, 2021 · 1 min · jiezi

关于高性能:RDMA打造存储利器

导读在数据一直增长的时代,数据的疾速解决对信息的无效利用至关重要。目前数据中心无论对存储读写带宽还是提早都有极致的要求,例如在线搜寻、挪动、游戏,视频直播畛域都须要以十分快的速度响应用户的申请,数据中心内任何一环导致提早,都会对用户体验产生极大的影响。 在高性能计算畛域,RDMA技术很早就曾经失去了验证,并且进行了肯定范畴的利用。随着大数据与人工智能的高速倒退,RDMA技术也将在企业内失去推广。 走进RDMA世界在TCP的网络世界里,收到一个网络数据包,要通过网络层和传输层,最初才可能被应用层解决。网络层和传输层会耗费CPU资源,因为CPU还要解决其余的计算工作,这一方面使得网络传输性能收到影响,同时也会影响其它计算工作的性能。此外,在进行传统的TCP协定解决时,所有的数据都须要在用户缓冲区与内核缓冲区之间进行屡次复制,须要耗费极大的内存带宽,同时带来肯定的延时。 RDMA技术就是为了升高网络传输中服务器端数据处理的提早而产生的。服务器网卡收到一个数据包,在网卡硬件上就能够实现网络层和传输层的解析,间接把数据传递给应用层,不须要CPU的干涉,从而开释内存带宽并缩小CPU耗费,进而晋升利用零碎性能。 为了无效利用RDMA技术的高带宽和低提早劣势,焱融云存储团队调研了反对RDMA技术的三种不同的网络协议: Infiniband(IB): 应用RMDA专用网卡与交换机,从硬件级别全面反对RDMA,保障传输可靠性RDMA OVER Converged Ethernet(RoCE):基于现有的以太网实现RDMA,底层网络包头部是一般的以太网包头,下层网络包头部是Infiniband包头,因而RoCE只须要专有的反对RoCE网卡,就能够在规范以太网基础架构(交换机)上实现RDMAInternet Wide Area RDMA Protocol(iWARP): iWARP间接将RDMA实现在了TCP上,这容许在规范以太网基础架构(交换机)上应用RDMA,这种计划须要配置反对iWARP的非凡网卡 比照三种协定实现,Infiniband性能最好,但须要额定配置较多的专用设备,零碎整体降级老本较高;RoCE只须要替换专用的网卡设施,在获取性能劣势的同时,将老本管制在肯定范畴;iWARP老本最低,但与TCP臃肿的协定栈相关联,性能上晋升无限。 焱融云分布式存储完满反对RDMA要实现反对RDMA网络的通信形式,须要应用RDMA verbs API(OFED 提供了蕴含libibverbs和RDMA-CM等用户态库函数)编程,对原有的通信模块进行改良,最终实现的网络传输模块既能兼容最后的TCP通信形式,又能够同时向客户端提供RDMA连贯服务。 焱融云技术团队在焱融高性能分布式存储里实现了RDMA传输的性能,反对通过InfiniBand,RoCE或TCP来实现客户端到存储服务端的数据交互,以及存储集群服务器之间的数据传输。 性能大幅晋升在性能上,咱们采纳Mellanox connect-X系列网卡以及Mellanox交换机基于以太网物理链路测试了RoCE的性能。从测试后果来看,绝对于TCP/IP通信协定, 小文件读写性能有了质的晋升。能够看到,基于RDMA技术的读写性能比基于一般交换机TCP传输的性能最高可晋升4倍。尤其是在小数据包的读写上,其性能劣势更为显著。 以上数据是基于RoCE形式实现的RDMA传输,如果应用专用的InfiniBand设施,其性能还会进一步晋升。有了RDMA这个利器,焱融云分布式存储在高性能计算、AI人工智能等畛域将更具劣势,满足用户在这些业务中对性能的更高要求。 在一个又一个的技术挑战背后,在谋求卓越的路线上,焱融云从未止步。

June 18, 2021 · 1 min · jiezi

关于高性能:针对-MySQL-IO-特点进行的存储优化揭秘

性能优化,是存储工程师们永远的谋求,在咱们看来,除了调整存储架构、优化IO门路,能对利用做出有针对性的优化,也是十分重要和有意义的事件,这意味着,除了要理解存储自身,还须要对下层利用或中间件有足够的意识。这次,咱们就来看看 MySQL 的 IO 特点和存储针对 MySQL 的优化思路。 MySQL 架构组件阐明MySQL 及其连续的 MariaDB 是目前市场上最风行的关系型数据库管理系统,在很多利用场景中,MySQL 都是用户首选的 RDBMS(Relational Database Management System关系数据库管理系统)。 MySQL大抵包含如下几大根底模块组件: MySQL客户端连贯组件(Connectors)系统管理和管制工具组件(Management Service & Utilities)连接池组件(Connection Pool)SQL组件( SQL Interface)解析器组件(Parser)查问优化器组件(Optimizer)缓存组件(Caches & Buffers)存储引擎(Pluggable Storage Engines)文件系统(File System) InnoDB 存储引擎存储引擎在 MySQL 的体系架构中位于第三层,负责对 MySQL 中的数据进行存储和提取,是与文件打交道的子系统,它是依据底层提供的文件拜访层形象接口定制的一种文件拜访机制,这个机制就叫作 MySQL 存储引擎。从 MySQL 5.5 开始,默认采纳 InnoDB 作为存储引擎。因而,优化底层存储对 MySQL 业务的的性能,就要从理解和剖析存储引擎如何与底层的存储系统进行交互开始。 下图是官网的 InnoDB 引擎架构图,InnoDB 存储引擎次要分为内存构造和磁盘构造两大部分。 InnoDB 磁盘次要蕴含 Tablespaces、InnoDB Data Dictionary、Doublewrite Buffer、Redo Log和 Undo Logs。Redo Log和 Binlog 是 MySQL 日志零碎中十分重要的两种机制,本文次要谈一下对 Redo Log 和 Binlog 进行的剖析及存储优化。 ...

June 16, 2021 · 1 min · jiezi

关于高性能:Serverless-over-Storage

什么是 Serverless?从英文的字面意思,跟 Serverful 比照,看起来如同是无服务器?但这显然不可能,毕竟无论如何,任何的程序最终都要在机器上执行。 要想了解 Serverless,咱们有必要回顾一下咱们通常的 Serverful 服务运行形式。 从 Serverful 到 Serverless 的演变物理机的应用形式仿佛素来都没有变动,无论是 10 年前,还是当初。典型的流程就是硬件洽购、拆箱、上电、做 Raid、插网线、调整交换机、做全面的配置查看,顺便还得查看一些内存、硬盘、固件的品质等等,因为说不定跑两天就挂了。整个环境上线,就是体力活。 虚拟化感触到了苦楚,就会促使工程师们去扭转。 曾经辛苦地筹备了硬件,当一个开发小哥须要一台机器的时候,作为 IT 管理人员,难道还要再次反复这个过程? 能够说虚拟化解放了 IT 管理者,通过在一台物理机上运行更多的虚拟机,晋升了资源利用率以达到更好的财务收益之外,虚拟化还给部署以及运行一台 “机器” 提供了极大的便当。 通过操作系统虚拟化一套硬件,再联合虚拟机模板镜像的机制,意味着在物理机上创立和挪动虚拟机也只是分分钟的事件而已。 以往的机器上线沉重、反复的膂力工作隐没殆尽。 云单机的虚拟化无奈满足大规模的场景,包含对调度,网络虚拟化的需要等等。此时,云横空出世,你既能够抉择私有云,也能够抉择本人搭建公有云,如 OpenStack。 甚至你都不须要关怀底层的硬件,只有是通用的架构即可,操作系统、网络、存储等均能够自动化装置、扩大进去。 然而,即便在云时代,应用软件的运行形式也没有变动,无非是软件看到的是一个虚构的硬件环境而已。对于使用者而言,不同的一点只是为软件筹备根底环境的过程变快了。 容器化只管虚拟化充分利用了资源,极大的进步了便利性,但技术倒退的车轮滚滚向前,工程师们总是得寸进尺。虚拟化仍旧存在比拟 “重” 的问题,镜像太大,多个虚拟机根本都蕴含反复的操作系统,物理机上无奈运行过多的虚拟机。 容器化,尤其是 2017 年以来 Kubernetes 的风行,又一次带来了扭转。容器只是一个轻量级的过程,而软件提供者只有保护一个 Dockerfile , 生成一个小得多的镜像,在容器平台部署即可。利用的上线不再关怀依赖、抵触,以及诸如 “我这里运行没问题,必定是你的环境问题” 等等困扰。 Serverless,更容易了解的一个名字是 functions-as-a-service,我想这样起名的一个初衷是让你不再关怀服务器,也不须要思考他们,只有执行你的代码就好。 构想一下即便是在容器化加持的状况下,利用开发者仍然要关注诸如 RestAPI 框架如何搭建、工作流怎么解决、压力来了怎么进行负载平衡、消息中间件如何解决等问题,有可能还要关怀平安降级、破绽扫描这些与业务逻辑关联不大的琐事。 2019,UC 伯克利大学发表了一篇“ Cloud Programming Simplified: A Berkeley View on Serverless Computing”的论文(https://www2.eecs.berkeley.ed... 论文中有一个很形象的比喻,形容如下: In the cloud context, serverful computing is like programming in low-level assembly language whereas serverless computing is like programming in a higher-level language such as Python. An assembly language programmer computing a simple expression such as c = a + b must select one or more registers to use, load the values into those registers, perform the arithmetic, and then store the result. This mirrors several of the steps of serverful cloud programming, where one first provisions resources or identifies available ones, then loads those resources with necessary code and data, performs the computation, returns or stores the results, and eventually manages resource release. The aim and opportunity in serverless computing is to give cloud programmers benefits similar to those in the transition to high-level programming languages. ...

June 1, 2021 · 2 min · jiezi

关于高性能:支持多套对象存储冷热数据分层又添新功能

传感器、爬虫、激光雷达、摄像头等前端设施和软件,以及大量用户,每天都在往企业外部输出大量非结构化数据,为了保留和保护好数据这个新型的生产因素,企业每年领取用于非结构化数据存储上的老本也在快速增长。 对于大多数企业用户而言,数据具备阶段性热点拜访的特点,超过肯定工夫后,80% 以上的数据逐渐转冷。热数据的拜访性能要求较高,通过肯定工夫周期之后,热数据逐步变冷,利用拜访这些冷数据的频率会变得很低。 如何解决海量非结构化数据存储及拜访性能,同时兼顾企业用户对非结构化数据的整体应用老本,是 CIO 们面临的次要问题。 YRCouldFile 文件存储系统的智能分层性能,能够依据用户须要,自定义冷热数据策略,冷数据主动流动至低成本的私有云对象存储并实现压缩,向上依然为业务提供规范的文件拜访接口,并放弃目录构造不变,数据在冷热数据层之间流动对业务齐全通明,能无效地对老本和性能做好均衡。 近期,焱融科技公布了 YRCloudFile 新版本,该版本对智能分层性能做了全面的降级,将分层策略细粒度到目录级别。例如目录 A 的冷数据下刷到阿里云 OSS,目录 B 的冷数据下刷到AWS 的 S3,目录 C 的冷数据下刷到本地对象存储。 细粒度的分层策略有什么益处呢? 冷数据定义更灵便 家喻户晓,私有云的对象存储的应用老本,有三局部组成,存储容量费用、API 调用费用、网络流入流出费用。很多时候,API 调用或者网络流入流出费用,往往比存储容量的费用要大的多。 数据趋冷是个逐渐的过程,在数据趋冷的过程中,有可能还是会被拜访,这部分费用加起来也是一笔收入。YRCloudFile 目录级智能分层性能推出,就能很好的解决这个问题。它能帮忙用户对冷热数据的辨别更细化,对于趋冷数据,寄存入本地对象存储,这部分数据可能还会有大量的拜访;对于更冷数据,能够设置目录连贯至有限容量的私有云对象存储上以作归档,这部分数据根本不再被调用。 So easy,不同利用,不同策略,不同对象存储厂商 对于数据中心而言,不同的利用,对冷数据的定义是不同的,对数据寄存的要求也不同。例如,数据安全要求高的冷数据要求寄存在本地;数据安全要求低的数据能够寄存在私有云。又如,训练数据在被频繁的训练 2 周之后就不再拜访,趋冷;训练后果数据则会在很长的时间段内始终须要频繁拜访。 基于不同利用类型以及不同数据安全的思考,咱们也须要更灵便,更简略的策略。YRCloudFile 能够对不同的场景、要求,定义不同的冷数据策略以及冷数据存储的地位。 任性,想存哪里就存哪里 冷数据不再被某家厂商绑定,您能够将冷数据寄存在寰球范畴内的各大公有云对象存储平台上,也能够抉择公有部署的商业对象存储,或者开源的 Ceph 等。对接了不同的平台,并不象征应用难度会减少,您能够应用简略的 UI 界面,轻松简略地解决 YRCloudFile 和不同对象存储平台的对接。 https://www.bilibili.com/vide... YRCloudFile 在谋求极致高性能的同时,也在一直的优化海量数据生命周期的治理。将来,咱们还会在数据生命周期治理上实现更多创新性的性能,敬请期待……

May 25, 2021 · 1 min · jiezi

关于高性能:并行文件存储和分布式-NFS-文件存储有何不同

文件存储作为存储三个接口状态中占比最高的一个(块、文件、对象),也有进一步的细分,不少用户困惑于并行文件系统和传统分布式 NFS 文件存储之间的区别,明天咱们来剖析一下二者有何不同。 在大多数状况下,用户在应用计算机时,不论是游戏、视频、文档编辑的一般应用程序,还是 AI、渲染、高性能计算的利用,这些利用应用的都是操作系统的“文件系统”。操作系统的“文件系统”模块提供了一个直观的界面(不光指咱们肉眼所看到的可视化的用户界面,同时也指从应用程序角度的 SDK 拜访接口)来拜访数据,而不会让您或应用程序记住数据在硬盘上的物理或逻辑地位(磁道,扇区号等)。 任何文件系统中都存在三个要害的形象: 文件:文件的实在数据可能不会在硬盘中的间断地位,但最终用户能够将文件以一长串间断字节的模式进行拜访(这是因为文件系统对硬盘的数据分布进行了形象和治理)。文件名:用户或应用程序能够通过诸如 doc01.txt 这类直观的文件名称拜访文件,而无需记住任何物理的存储信息。目录树:文件系统(不论是本地的 ext4、xfs 文件系统,还是近程的共享文件系统)以目录树的模式治理所有文件。 NFS NFS(Network File System,网络文件系统),是 Sun 基于 C/S 架构开发的一个文件系统,它容许用户通过网络拜访文件,用户在应用的时候,感觉这些文件就像是位于本地文件目录中。这是通过 NFS 服务器导出(/etc/exports),并提供相应的文件拜访权限,和 NFS 客户端挂载(使文件系统可用于应用程序所处的操作系统)的过程来实现的。 并行文件系统 并行文件系统中,文件数据被切分并搁置到多个存储设备中(各个被切分的数据如何搁置,由并行文件系统通过算法来管制,能够基于元数据服务或相似一致性哈希的形式实现),零碎应用全局名称空间来进行数据拜访。并行文件系统的客户端能够同时应用多个 IO 门路将数据读/写到多个存储设备。 并行文件系统 vs 分布式文件系统 并行文件系统是分布式文件系统的一种。分布式文件系统和并行文件系统都能够将数据分布在多个存储服务器上,可横向扩大从而包容PB级数据,并反对高带宽。 分布式文件系统通常也像并行文件系统一样,反对共享的全局名称空间。然而对于分布式文件系统而言,即便局部文件数据被调配和搁置在不同服务器上,客户端在拜访数据或元数据时,依然须要通过指定的协定服务器来实现,协定服务器可能会成为 IO 路由的瓶颈。当初市场上支流的分布式文件存储为了解决这个协定服务器瓶颈的问题,应用 DNS 技术将不同的客户端连贯至多个协定服务器,实现肯定水平的负载平衡,但即便通过负载散发,也只是将不同客户端的 IO 拆分至多个协定服务器,协定服务器依然须要进行一次 IO 转发,从而带来肯定水平的性能损耗。应用并行文件系统,客户端零碎能够间接拜访所有存储节点以进行数据传输,而不用通过协定服务器。 其余区别还包含: 分布式文件系统通常应用规范的网络文件拜访协定(例如 NFS 或 SMB )来拜访存储服务器。并行文件系统通常须要装置基于客户端的软件驱动程序(甚至推出基于 Windows 的客户端程序,例如 YRCloudFile、Panasas 等),通过以太网或 InfiniBand 等高速网络访问共享存储,因为只有基于这些客户端程序,能力实现区别于 NFS 的多 IO 门路拜访。局部分布式文件系统将单个文件存储在单个存储节点上,而并行文件系统通常将文件合成并跨多个存储节点对数据块进行条带化。分布式文件系统偏向于带宽型或归档型应用程序。并行文件系统专一于高并发、高IOPS、海量数据的高性能工作负载。分布式文件系统通常应用诸如三正本或纠删码等技术来提供数据可靠性,而许多并行文件系统还反对后端挂载磁盘阵列(例如 Lustre、Spectrum Scale、YRCloudFile 等)。

May 21, 2021 · 1 min · jiezi

关于高性能:深入浅出分布式存储性能优化方案

Latency指标对于存储系统性能的重要性咱们剖析一套分布式存储系统,次要从可靠性、易用性和性能三个维度着手剖析。 可靠性:是存储系统的基石,一款存储系统至多须要提供99.99%的数据可靠性,数据失落或者错乱对于存储系统是致命的,对大数据、云存储这样大规模的分布式集群 易用性:是系统管理员最关怀的问题,次要体现产品设计、故障解决和零碎的扩展性 性能:如果可靠性是存储系统的基石,那么性能是存储系统的灵魂,对一款优良存储系统,高牢靠与高性能缺一不可 本文将从性能的维度剖析分布式存储系统,那么如何剖析一款分布式存储系统的性能呢? 让咱们先理解评测存储系统的主要参数:IO Type、IO Mode、IO Size和IO Concurrency;这些参数的值的不同组合对应了不同的业务模型,场景的模型如下表所示: 表一:罕用业务类型 注1:SPC-1,次要掂量存储系统在随机小IO负荷下的IOPS,而SPC-2则次要掂量在各种高负荷间断读写利用场合下存储系统的带宽。 注2:SPC-1将测试区域形象为ASU,ASU分为三类:ASU1长期数据区域,ASU2用户数据区域和ASU3日志区域。 依据上表可知,因为业务类型是多种多样的,很难做到全面笼罩,通常应用三个性能指标:IOPS、Throughput和Latency来测评一款存储系统。通常,大IO应用指标Throughput来评测零碎性能;小IO应用IOPS来评测零碎性能。那么,性能指标:Latency的作用是什么?并且Latency指标往往容易在性能评测中被忽视。在这里介绍一下性能指标Latency的作用,用户评测一款存储系统之前,测试零碎的IOPS和Throughput都很称心,但上线后,反映业务零碎卡顿,其外围便是Latency过高。 上面援用一段网络博文:“即便供应商新型的存储系统在60/40混合读写条件下能奇迹般地实现1,000,000 4K随机IOPS,我还是想晓得它的提早是多少。Dimitris Krekoukias在最近的一篇对于IOPS和提早的博客中写道:某供应商的零碎能实现15000的IOPS,均匀提早为25ms。然而数据库引擎还是提醒高水平I/O等待时间。 一位批评家在Krekoukias's Ruptured Monkey博客中具体叙述了只有在提早小于4ms的状况下,信用卡处理器才不会减慢防欺骗或提款受权等过程。”同样,冬瓜哥在博文中解说了如何了解时延,这里简略复述下:“每秒执行 1000 个 IO ,均匀每个 IO 的执行消耗了 1000ms/1000IOPS=1ms ,所以每个 IO 的均匀时延就是 1ms,这有什么不对呢?”下面的计算疏忽了并发度这个因素。对于异步、高并发的业务,这个存储系统能够满足业务需要。但基于OLTP和OLAP的业务个别是同步的且低并发的业务,这款存储系统是否满足业务需要,这仍是一个问号。 通过下面的材料咱们得出:实现高性能的要害是高IOPS和低Latency的联合。当存储系统提供更高的IOPS时,单IO的时延不应同步进步过多,否则将影响业务零碎的性能。比方JetStress倡议均匀时延应小于20ms,最大值应小于100ms。 分布式存储中的Latency问题咱们先看下传统存储的时延,在传统存储系统中,其IO时延有着人造的劣势。劣势一是物理IO门路较短,通常为机头控制器后端再挂载JBOD;劣势二是应用Raid5、RAID10或者RAID 2.0等数据保护算法,这些算法是基于Disk或者Chunk,比基于故障域的正本模式开销小很多。 图一:传统SAN IO架构 图二:Raid 2.0原理 在分布式存储中,由多台或者上百台的服务器组成,且应用正本模式。所以一个IO通过网络,在多个正本服务器上解决,且每个正本都有数据一致性查看算法,这些操作都将减少IO的时延。 图三:分布式集群IO流 从上图可知,三正本的分布式存储系统,一个写IO,须要从写Leader和写两个Follower实现后才返回给user; 分布式存储的正本模式对性能的影响到底有多大呢?为了理性的意识,咱们先看两个性能比照: 图四:在本地存储跑OLTP业务 图五:在分布式存储上跑OLTP业务 依据下面两图的性能数据,分布式存储的IO时延确实很高。 分布式存储系统的另一个性能问题是IO的抖动,体现在时延上是均匀时延与最小时延和最大时延偏离值很大,呈现这个问题的次要起因是散布零碎的架构原理与IO申请处理不当引起;比方,正本之间的强一致性,只有有一个正本响应稍慢,整个IO的时延将减少或者一致性算法引起IO短暂沉积,IO都发送到雷同的存储节点。 焱融自研分布式存储cache引擎对于如何升高分布式存储Latency,其实是一个零碎又简单的事件,牵一发而动全身,让咱们先来看看阿里云云存储和华为的闪存阵列都做了哪些工作: 阿里云ESSD硬件降级:服务器、SSD、网络(40GB/s, 25GB/s)、网络交换机、RDMA协定网络通信框架:Luna, RDMA+用户态驱动+公有I/O协定线程模型改良:用户态驱动,退出co-routine协程,加run to completion模式数据布局:采纳追加写,批改元数据模式(元数据记录数据的地位)更粗疏的分层和形象;针对不同的IO属性,提供更定制化的策略模块,满足不同的IO Profile需要 华为闪存OceanStor Dorado V3硬件优化,硬盘框采纳12Gbps的SAS直连管制框模式;精简NVMe SSD协定对时延敏感的要害解决不被频繁打断、不被其余工作阻塞处理器分组技术,将处理器中的各个核依照业务需要划分成不同的分区,要害业务在各个分区上运行,不被打断为了保障申请的稳固低时延,读申请和写入cache的写申请能够在存储系统内优先领有各种要害的解决资源,包含:cpu、内存、访盘并发等;cache异步刷盘的申请优先级低无效聚合,保障大块程序写入SSD,实现申请解决效率最优冷热数据分区,缩小写放大,晋升性能充分发挥SSD的垃圾回收机制,在擦除块时缩小数据搬移量,较少对SSD的性能和寿命的影响 等等。。。 可见通常进步性能,优化时延的次要办法概括起来有以下几个方面: 硬件降级,诸如NVMe,RDMA优化IO门路,通信框架优化每个模块的解决工夫优化磁盘布局减少数据缓存层以NVMe为例,NVMe驱动层间接透过SCSI协定栈,由驱动层与通用块层间接交互,以达到升高IO时延的指标,同时应用通用块层的多队列机制,进一步的晋升性能。不过这种形式的弊病是对于客户的成本上升较高。 图七:通用存储设备协定栈与NVMe协定栈 个别存储厂商的通用无效形式是利用减少数据缓存层来升高提早,即利用在存储节点给多块HDD配置一块SSD,再应用开源BCache计划,此种计划是一种通用的经济实惠解决方案。如下图所示,不过这种计划对性能晋升无限,次要起因还是IO门路过长,分布式存储核心层逻辑过于简单,同时采纳开源BCache计划也存在着很多问题诸如:BCache尽管开源,但如果呈现问题,根本没有保护的能力;BCache减少运维难度;BCache对成员盘的故障解决能力较弱。 ...

May 19, 2021 · 1 min · jiezi

关于高性能:文件系统中的锁

在多过程共享的应用程序中,通过“锁”来对同一个计算资源进行协同是十分常见的做法,无论在单机或多机的零碎、数据库、文件系统中,都须要依赖“锁”机制来防止并发拜访导致的不确定后果,明天咱们就来讲讲文件系统中的“锁”。 首先,文件锁也是一种互斥机制,可确保多个过程以平安的形式读取/写入同一个文件。之所以要对这些多过程业务进行管制,就是因为这些过程的调度是不可预期的,这种时序上的不可预期会对同一个文件资源产生竞争性拜访,从而带来预期外的后果。 咱们能够看一个例子,以便更好地了解这个问题。 假如咱们有一个 account.dat 文件,用于存储帐户余额,其初始值为“200”。并发零碎有两个过程来更新这个文件上的余额值: 过程 A:读取以后值,减去 20,而后将后果保留回文件中。过程 B:读取以后值,加 80,而后将后果写回到文件中。显然,在程序执行完这两个过程后,咱们冀望文件具备以下值:200-20 + 80 = 260。 然而,如果过程的执行不是按预期的程序直径,在以下这种状况下,可能会呈现不一样的后果: 过程 A 读取文件的以后值(200),并筹备进行进一步的计算。这时,过程 B 读取雷同的文件并取得以后余额(200)。过程 A 计算 200-20 并将后果 180 保留回文件。过程 B 不晓得余额已更新。因而,它仍将应用过期的值 200 计算 200 + 80,并将后果 280 写入文件。后果,account.dat 文件中保留的余额就是 280 而不是预期值 260。 Linux 中的文件锁 像后面提到的,文件锁是一种在多个过程之间限度文件并发拜访的机制。它仅容许一个过程在特定工夫内拜访文件,从而防止更新问题。 咱们都晓得 rm -rf /在 Linux 中是十分危险的命令。如果咱们以 root 用户身份执行该命令,它甚至能够删除正在运行的零碎中的所有文件。这是因为 Linux 通常不会主动给关上的文件加锁,所以即便是正在运行的文件,依然有可能被 rm 命令删除。Linux 反对两种文件锁:协同锁(Advisory lock)和强制锁(Mandatory lock)。 协同锁(Advisory lock) 协同锁定不是强制性锁计划,仅当参加的过程通过显式获取锁进行合作时,它才无效。否则,如果某个过程基本不晓得锁,则这个协同锁会被疏忽掉(意味着各个过程间必须协商并恪守这个协同锁的机制,能力施展锁的作用)。 上面这个例子能够帮忙咱们更容易地了解协同锁机制。让咱们先回顾一下咱们之前提到的账户文件的例子。 首先,咱们假如文件 account.dat 仍蕴含初始值 “200”。 过程 A 获取 account.dat 文件的排他锁,而后关上并读取该文件以获取以后值:200。 ...

May 10, 2021 · 1 min · jiezi

关于高性能:从根上理解高性能高并发二深入操作系统理解IO与零拷贝技术

1、系列文章引言1.1 文章目标作为即时通讯技术的开发者来说,高性能、高并发相干的技术概念早就了然与胸,什么线程池、零拷贝、多路复用、事件驱动、epoll等等名词信手拈来,又或者你对具备这些技术特色的技术框架比方:Java的Netty、Php的workman、Go的nget等熟练掌握。但真正到了面视或者技术实际过程中遇到无奈释怀的纳闷时,方知自已所把握的不过是皮毛。 返璞归真、回归实质,这些技术特色背地的底层原理到底是什么?如何能通俗易懂、毫不费力真正透彻了解这些技术背地的原理,正是《从根上了解高性能、高并发》系列文章所要分享的。 1.2 文章源起我整顿了相当多无关IM、音讯推送等即时通讯技术相干的资源和文章,从最开始的开源IM框架MobileIMSDK,到网络编程经典巨著《TCP/IP详解》的在线版本,再到IM开发纲领性文章《新手入门一篇就够:从零开发挪动端IM》,以及网络编程由浅到深的《网络编程懒人入门》、《脑残式网络编程入门》、《高性能网络编程》、《鲜为人知的网络编程》系列文章。 越往常识的深处走,越感觉对即时通讯技术理解的太少。于是起初,为了让开发者门更好地从根底电信技术的角度了解网络(尤其挪动网络)个性,我跨专业收集整理了《IM开发者的零根底通信技术入门》系列高阶文章。这系列文章未然是一般即时通讯开发者的网络通信技术常识边界,加上之前这些网络编程材料,解决网络通信方面的常识盲点根本够用了。 对于即时通讯IM这种零碎的开发来说,网络通信常识的确十分重要,但回归到技术实质,实现网络通信自身的这些技术特色:包含下面提到的线程池、零拷贝、多路复用、事件驱动等等,它们的实质是什么?底层原理又是怎么?这就是整顿本系列文章的目标,心愿对你有用。 1.3 文章目录1)《从根上了解高性能、高并发(一):深刻计算机底层,了解线程与线程池》2)《从根上了解高性能、高并发(二):深刻操作系统,了解I/O与零拷贝技术》(* 本文)3)《从根上了解高性能、高并发(三):深刻操作系统,彻底了解I/O多路复用 (稍后公布..)》4)《从根上了解高性能、高并发(四):深刻操作系统,彻底了解同步与异步 (稍后公布..)》5)《从根上了解高性能、高并发(五):高并发高性能服务器到底是如何实现的 (稍后公布..)》1.4 本篇概述接上篇《深刻计算机底层,了解线程与线程池》,本篇是高性能、高并发系列的第2篇文章,在这里咱们来到了I/O这一话题。你有没有想过,当咱们执行文件I/O、网络I/O操作时计算机底层到底产生了些什么?对于计算机来说I/O是极其重要的,本篇将带给你这个问的答案。 2、本文作者应作者要求,不提供真名,也不提供集体照片。 本文作者次要技术方向为互联网后端、高并发高性能服务器、检索引擎技术,网名是“码农的荒岛求生”,公众号“码农的荒岛求生”。感激作者的自私分享。 3、不能执行I/O的计算机是什么?置信对于程序员来说I/O操作是最为相熟不过的了,比方: 1)当咱们应用C语言中的printf、C++中的"<<",Python中的print,Java中的System.out.println等时;2)当咱们应用各种语言读写文件时;3)当咱们通过TCP/IP进行网络通信时;4)当咱们应用鼠标龙飞凤舞时;5)当咱们拿起键盘在评论区指点江山亦或是埋头苦干致力制作bug时;6)当咱们能看到屏幕上的丑陋的图形界面时等等。以上这所有,都是I/O! 想一想:如果没有I/O计算机该是一种如许干燥的设施,不能看电影、不能玩游戏,也不能上网,这样的计算机最多就是一个大号的计算器。 既然I/O这么重要,那么到底什么才是I/O呢? 4、什么是I/O?I/O就是简略的数据Copy,仅此而已! 这一点很重要! 既然是copy数据,那么又是从哪里copy到哪里呢? 如果数据是从外部设备copy到内存中,这就是Input。 如果数据是从内存copy到外部设备,这就是Output。 内存与外部设备之间不嫌麻烦的来回copy数据就是Input and Output,简称I/O(Input/Output),仅此而已。 5、I/O与CPU当初咱们晓得了什么是I/O,接下来就是重点局部了,大家留神,坐稳了。 咱们晓得当初的CPU其主频都是数GHz起步,这是什么意思呢? 简略说就是:CPU执行机器指令的速度是纳秒级别的,而通常的I/O比方磁盘操作,一次磁盘seek大略在毫秒级别,因而如果咱们把CPU的速度比作战斗机的话,那么I/O操作的速度就是肯德鸡。 也就是说当咱们的程序跑起来时(CPU执行机器指令),其速度是要远远快于I/O速度的。那么接下来的问题就是二者速度相差这么大,那么咱们该如何设计、该如何更加正当的高效利用系统资源呢? 既然有速度差别,而且过程在执行完I/O操作前不能持续向前推动,那么显然只有一个方法,那就是期待(wait)。 同样是期待,有聪慧的期待,也有傻傻的期待,简称傻等,那么是抉择聪慧的期待呢还是抉择傻等呢? 假如你是一个急性子(CPU),须要期待一个重要的文件,不巧的是这个文件只能快递过去(I/O),那么这时你是抉择什么事件都不干了,深情的凝视着门口就像盼望着你的哈尼一样分心期待这个快递呢?还是临时先不要管快递了,玩个游戏看个电影刷会儿短视频等快递来了再说呢? 很显然,更好的办法就是先去干其它事件,快递来了再说。 因而:这里的关键点就是快递没到前手头上的事件能够先暂停,切换到其它工作,等快递过去了再切换回来。 了解了这一点你就能明确执行I/O操作时底层都产生了什么。 接下来让咱们以读取磁盘文件为例来解说这一过程。 6、执行I/O时底层都产生了什么在上一篇《深刻计算机底层,了解线程与线程池》中,咱们引入了过程和线程的概念。 在反对线程的操作系统中,实际上被调度的是线程而不是过程,为了更加清晰的了解I/O过程,咱们临时假如操作系统只有过程这样的概念,先不去思考线程,这并不会影响咱们的探讨。 当初内存中有两个过程,过程A和过程B,以后过程A正在运行。 如下图所示: 过程A中有一段读取文件的代码,不论在什么语言中通常咱们定义一个用来装数据的buff,而后调用read之类的函数。 就像这样: read(buff);这就是一种典型的I/O操作,当CPU执行到这段代码的时候会向磁盘发送读取申请。 留神:与CPU执行指令的速度相比,I/O操作操作是十分慢的,因而操作系统是不可能把贵重的CPU计算资源节约在无谓的期待上的,这时重点来了,留神接下来是重点哦。 因为外部设备执行I/O操作是相当慢的,因而在I/O操作实现之前过程是无奈持续向前推动的,这就是所谓的阻塞,即通常所说的block。 操作系统检测到过程向I/O设施发动申请后就暂停过程的运行,怎么暂停运行呢?很简略:只须要记录下以后过程的运行状态并把CPU的PC寄存器指向其它过程的指令就能够了。 过程有暂停就会有继续执行,因而操作系统必须保留被暂停的过程以备后续继续执行,显然咱们能够用队列来保留被暂停执行的过程。 如下图所示,过程A被暂停执行并被放到阻塞队列中(留神:不同的操作系统会有不同的实现,可能每个I/O设施都有一个对应的阻塞队列,但这种实现细节上的差别不影响咱们的探讨)。 这时操作系统曾经向磁盘发送了I/O申请,因而磁盘driver开始将磁盘中的数据copy到过程A的buff中。尽管这时过程A曾经被暂停执行了,但这并不障碍磁盘向内存中copy数据。 留神:古代磁盘向内存copy数据时无需借助CPU的帮忙,这就是所谓的DMA(Direct Memory Access)。 这个过程如下图所示: 让磁盘先copy着数据,咱们接着聊。 实际上:操作系统中除了有阻塞队列之外也有就绪队列,所谓就绪队列是指队列里的过程准备就绪能够被CPU执行了。 你可能会问为什么不间接执行非要有个就绪队列呢?答案很简略:那就是口多食寡,在即便只有1个核的机器上也能够创立出成千上万个过程,CPU不可能同时执行这么多的过程,因而必然存在这样的过程,即便其所有准备就绪也不能被调配到计算资源,这样的过程就被放到了就绪队列。 当初过程B就位于就绪队列,万事俱备只欠CPU。 如下图所示: ...

December 28, 2020 · 1 min · jiezi

SOFAJRaft-日志复制-pipeline-实现剖析-SOFAJRaft-实现原理

SOFAStack(Scalable Open Financial  Architecture Stack)是蚂蚁金服自主研发的金融级分布式架构,包含了构建金融级云原生架构所需的各个组件,是在金融场景里锤炼出来的最佳实践。SOFAJRaft 是一个基于 Raft 一致性算法的生产级高性能 Java 实现,支持 MULTI-RAFT-GROUP,适用于高负载低延迟的场景。 本文为《剖析 | SOFAJRaft 实现原理》第六篇,本篇作者徐家锋,来自专伟信息,力鲲,来自蚂蚁金服。《剖析 | SOFAJRaft 实现原理》系列由 SOFA 团队和源码爱好者们出品,项目代号:<SOFA:JRaftLab/>,文章尾部有参与方式,欢迎同样对源码热情的你加入。 SOFAJRaft :https://github.com/sofastack/sofa-jraft 本文的目的是要介绍 SOFAJRaft 在日志复制中所采用的 pipeline 机制,但是作者落笔时突然觉得这个题目有些唐突,我们不应该假设读者理所应当的对日志复制这个概念已经了然于胸,所以作为一篇解析,我觉得还是应该先介绍一下 SOFAJRaft 中的日志复制是要解决什么问题。 概念介绍SOFAJRaft 是对 Raft 共识算法的 Java 实现。既然是共识算法,就不可避免的要对需要达成共识的内容在多个服务器节点之间进行传输,在 SOFAJRaft 中我们将这些内容封装成一个个日志块 (LogEntry),这种服务器节点间的日志传输行为在 SOFAJRaft 中也就有了专门的术语:日志复制。 为了便于阅读理解,我们用一个象棋的故事来类比日志复制的流程和可能遇到的问题。 假设我们穿越到古代,要为一场即将举办的象棋比赛设计直播方案。当然所有电子通讯技术此时都已经不可用了,幸好象棋比赛是一种能用精简的文字描述赛况的项目,比如:“炮二平五”, “马8进7”, “车2退3”等,我们将这些描述性文字称为棋谱。这样只要我们在场外同样摆上棋盘 (可能很大,方便围观),通过棋谱就可以把棋手的对弈过程直播出来。 图1 - 通过棋谱直播 所以我们的直播方案就是:赛场内两位棋手正常对弈,设一个专门的记录员来记录棋手走出的每一步,安排一个旗童飞奔于赛场内外,棋手每走一步,旗童就将其以棋谱的方式传递给场外,这样观众就能在场外准实时的观看对弈的过程,获得同观看直播相同的体验。 图2 - 一个简单的直播方案 这便是 SOFAJRaft 日志复制的人肉版,接下来我们完善一下这个“直播系统”,让它逐步对齐真实的日志复制。 改进1. 增加记录员的数量假设我们的比赛获得了很高的关注度,我们需要在赛场外摆出更多的直播场地以供更多的观众观看。 这样我们就要安排更多的旗童来传递棋谱,场外的每一台直播都需要一个旗童来负责,这些旗童不停的在赛场内外奔跑传递棋谱信息。有的直播平台离赛场远一些,旗童要跑很久才行,相应的直播延迟就会大一些,而有些直播平台离得很近,对应的旗童就能很快的将对弈情况同步到直播。 随着直播场地的增加,负责记录棋局的记录员的压力就会增加,因为他要针对不同的旗童每次提供不同的棋谱内容,有的慢有的快。如果记录员一旦记混了或者眼花了,就会出现严重的直播事故(观众看到的不再是棋手真正的棋局)。 图4 - 压力很大的记录员 ...

August 7, 2019 · 2 min · jiezi

消息点击率翻倍的背后闲鱼无侵入可扩展IFTTT系统

一、面临问题在闲鱼生态里,用户之间会有很多种关系。其中大部分关系是由买家触发,联系到卖家,比如买家通过搜索、收藏、聊天等动作与卖家产生联系;另外一部分是平台与用户之间的关系。对这些关系分析之后我们发现这些关系中存在两个问题: 用户产生关系的层次不够丰富;现有系统只维护了一部分用户关系,包括收藏、点赞等,用户关系的层次还不够丰富。用户之间关系是单向且不够实时;在现有的玩法中,买家可以通过多种行为与卖家产生联系,但卖家不能主动与买家发生关系和互动;而且平台计算的关系都是离线的,对用户的吸引力不足。上面提到的场景经过抽象归纳之后都是同一个范式:当某个条件被满足之后,就会触发相对应的动作。这个范式是IFTTT的基本理念,而闲鱼IFTTT就是对这些问题的解决方案。 二、IFTTT概念IFTTT是一个被称为 “网络自动化神器” 的创新型互联网服务理念,它很实用而且概念很简单。IFTTT全称是 If this then that,意思是如果满足“this”条件,则触发执行“that”动作。IFTTT由三部分构成,分别为Trigger、Action和Recipe。 可以看出IFTTT本身概念并不复杂,它的真正魔力在于“由简单组成的复杂”,也就是由众多简单的IFTTT流程相互衔接成跨越整个互联网、跨越多平台、跨越多设备的状态机。 2.1、闲鱼IFTTT闲鱼IFTTT是基于闲鱼的业务场景与IFTTT理念结合后产生的,提供IFTTT标准协议封装,对业务无侵入可扩展的服务编排系统。 闲鱼IFTTT的两个特性对应上述两个问题,分别是: 多维用户关系感知多维指的是覆盖面,闲鱼IFTTT通过更多维度的挖掘,抽象并维护了更丰富的用户关系。基于用户关系数据,我们可以产出用户画像,并通过更有效的方式触达用户。 实时用户双向互动闲鱼IFTTT底层具有对用户关系大数据的高效存储和处理能力,以支持上层业务中用户关系实时处理;闲鱼IFTTT不仅支持买家到卖家关系,而且通过设计天生支持卖家到买家关系。 闲鱼IFTTT把之前平台与用户的互动、买家到卖家的联系,切换称闲鱼用户之间天然的关系互动,对用户骚扰更少且激活拉回的效果更好,我们基于这个场景设计闲鱼IFTTT的技术方案。 三、技术方案 首先按照IFTTT规范对业务进行建模,分为Channel、Trigger和Action层,其中Channel层是数据底层,将Trigger和Action关联后组成标准Recipe。 ChannelChannel层在闲鱼IFTTT的作用是保存和管理用户关系数据,Channel层定义了用户关系的元数据结构,包括关系类型、源账户和目标账户。Channel层是闲鱼IFTTT的基石,Trigger和Action均基于用户关系数据进一步抽象业务逻辑。TriggerTrigger是业务上自定义的触发事件,与业务息息相关,可能是关注的人上新、浏览宝贝降价或者是参加的百币夺宝活动开奖等。当Trigger触发后,闲鱼IFTTT会根据Trigger类型和配置的关系类型计算用户名单,并调用Action层进行处理。ActionAction层处理对象是Trigger触发后计算的用户名单,可以给名单里的用户发Push,发权益或者其他定制逻辑。Action本身是标准化、可插拔的组件,业务上可以利用Action组件对用户名单做AB测试,快速实验不同Action策略。接下来我们说一下闲鱼IFTTT详细技术方案,方案如下: 整体技术方案按照业务建模的结构图细化,补充依赖的技术组件。整体流程不再细述,针对流程中重点模块详细说明。 3.1、场景快速接入设计场景快速接入的目的是让业务对接入闲鱼IFTTT无感知,因为在最开始的设计中,场景接入是准备通过在业务逻辑里增加AOP切面,将业务数据和场景上报。但因为这种方式对业务本身有一定侵入,增加业务执行的RT而且不够灵活,最终被否决。 而现在的场景快速接入方案解决了这些问题,通过SLS接入所有应用的海量网络请求日志,记录请求的URL、参数和响应;将SLS作为Blink流计算任务的数据源;根据diamond动态下发的规则实时筛选网络请求URL和参数,把数据按照指定格式组装后上报给Channel层。 场景快速接入方案将业务逻辑与场景接入解耦,支持快速接入,灵活变更且延迟低,是针对大数据场景接入的高性能解决方案。 3.2、计算用户名单计算用户名单模块采用责任链模式设计,因为在不同Trigger场景中,业务对用户名单的计算和筛选逻辑都是不同的。通过责任链模式,将主流程与业务筛选逻辑解耦,并支持各业务灵活定制筛选逻辑,互不干扰。 3.3、PushActionAction层是闲鱼IFTTT中最重要的一环,会直接触达到用户,Action的逻辑会直接影响用户对平台的直观感受和活跃率。消息Push是Action中最常见的逻辑,更要防止用户被骚扰,PushAction逻辑如下: 敏感人群过滤;疲劳度校验;对发送人群进行AB实验;组装消息;将Action各节点日志同步到SLS,方便检索和排查问题;统计消息发送数据及点击数据,为业务后续决策提供依据;3.3.1、疲劳度疲劳度是防止用户被骚扰的关键,我们针对疲劳度进行了分层设计,分为三层,第一层为用户级别疲劳度,控制一个用户在一个周期内收到消息数量;第二层是业务维度,控制用户在一个周期内收到某个业务的消息数量;第三层是目标级别,控制用户在一个周期内收到同一个发送者消息数量。 在业务维度层面,支持灵活控制多个业务联合疲劳度,保证用户不会被消息过度骚扰。 3.4、用户关系存储用户关系数据是闲鱼IFTTT的基石,它的特点是存储量级大,达到TB级别;而且对存储和查询的性能要求高,TPS和QPS的峰值都在一万以上。经过调研,我们发现集团内部开发的Lindorm可以满足需求。 Lindorm是阿里内部基于Hbase自研的高性能KV存储数据库,对Hbase的性能和稳定性均有一定优化。闲鱼IFTTT采用Lindorm作为用户关系数据存储,经性能测试验证数据读取QPS达到7万,数据存储TPS在10万以上。Lindorm本身性能优异,为闲鱼IFTTT高性能奠定基础。 四、效果验证闲鱼IFTTT自上线以来,已支持关注上新、浏览宝贝降价和租房小区上新等多个业务场景,提供买卖双方实时双向互动能力,平均每天处理关系数据数亿条,处理Trigger量达到上千万,处理Action量达到亿级别,消息点击率较离线push提高1倍以上。 闲鱼IFTTT目前支持的是用户互动场景,后续我们将结合闲鱼自身业务特点,对IFTTT进行更高维度抽象,封装标准Recipe接口,将闲鱼IFTTT打造成提供流程编排、管理能力的服务平台。 在我看来,IFTTT从2010年推出以来,在国外有很大的热度,在互联网和物联网领域都有专门的公司和团队在研发,IFTTT的概念虽然简单,却通过标准化协议满足用户的强需求-让各种互联网产品为用户服务。这其实也给我们互联网从业者一些思考:在新机遇面前,究竟是快速投入比较重要还是抽象标准协议解决一类问题更加有效? 五、名词注解SLS:https://cn.aliyun.com/product/slsDiamond:阿里内部研发的持久配置管理中间件;Blink:https://data.aliyun.com/product/sc?spm=5176.10695662.1131226.1.bf495006EWuVABMetaQ:阿里内部研发的分布式、队列模型的消息中间件;Lindorm:阿里内部基于HBase研发的新一代分布式NoSQL数据库,阿里云类似产品:https://www.aliyun.com/product/ots?spm=a2c4g.11174283.cwnn_jpze.59.2f5a15c3NH30me;Tair:阿里内部研发的高性能、分布式、可扩展、高可靠的Key-Value结构存储系统; 本文作者:闲鱼技术-剑辛阅读原文 本文为云栖社区原创内容,未经允许不得转载。

June 17, 2019 · 1 min · jiezi

消息点击率翻倍的背后闲鱼无侵入可扩展IFTTT系统

一、面临问题在闲鱼生态里,用户之间会有很多种关系。其中大部分关系是由买家触发,联系到卖家,比如买家通过搜索、收藏、聊天等动作与卖家产生联系;另外一部分是平台与用户之间的关系。对这些关系分析之后我们发现这些关系中存在两个问题: 用户产生关系的层次不够丰富;现有系统只维护了一部分用户关系,包括收藏、点赞等,用户关系的层次还不够丰富。用户之间关系是单向且不够实时;在现有的玩法中,买家可以通过多种行为与卖家产生联系,但卖家不能主动与买家发生关系和互动;而且平台计算的关系都是离线的,对用户的吸引力不足。上面提到的场景经过抽象归纳之后都是同一个范式:当某个条件被满足之后,就会触发相对应的动作。这个范式是IFTTT的基本理念,而闲鱼IFTTT就是对这些问题的解决方案。 二、IFTTT概念IFTTT是一个被称为 “网络自动化神器” 的创新型互联网服务理念,它很实用而且概念很简单。IFTTT全称是 If this then that ,意思是如果满足“this”条件,则触发执行“that”动作。IFTTT由三部分构成,分别为Trigger、Action和Recipe。 可以看出IFTTT本身概念并不复杂,它的真正魔力在于“由简单组成的复杂”,也就是由众多简单的IFTTT流程相互衔接成跨越整个互联网、跨越多平台、跨越多设备的状态机。 2.1、闲鱼IFTTT闲鱼IFTTT是基于闲鱼的业务场景与IFTTT理念结合后产生的,提供IFTTT标准协议封装,对业务无侵入可扩展的服务编排系统。 闲鱼IFTTT的两个特性对应上述两个问题,分别是: 多维用户关系感知多维指的是覆盖面,闲鱼IFTTT通过更多维度的挖掘,抽象并维护了更丰富的用户关系。基于用户关系数据,我们可以产出用户画像,并通过更有效的方式触达用户。 实时用户双向互动闲鱼IFTTT底层具有对用户关系大数据的高效存储和处理能力,以支持上层业务中用户关系实时处理;闲鱼IFTTT不仅支持买家到卖家关系,而且通过设计天生支持卖家到买家关系。 闲鱼IFTTT把之前平台与用户的互动、买家到卖家的联系,切换称闲鱼用户之间天然的关系互动,对用户骚扰更少且激活拉回的效果更好,我们基于这个场景设计闲鱼IFTTT的技术方案。 三、技术方案 首先按照IFTTT规范对业务进行建模,分为Channel、Trigger和Action层,其中Channel层是数据底层,将Trigger和Action关联后组成标准Recipe。 ChannelChannel层在闲鱼IFTTT的作用是保存和管理用户关系数据,Channel层定义了用户关系的元数据结构,包括关系类型、源账户和目标账户。Channel层是闲鱼IFTTT的基石,Trigger和Action均基于用户关系数据进一步抽象业务逻辑。TriggerTrigger是业务上自定义的触发事件,与业务息息相关,可能是关注的人上新、浏览宝贝降价或者是参加的百币夺宝活动开奖等。当Trigger触发后,闲鱼IFTTT会根据Trigger类型和配置的关系类型计算用户名单,并调用Action层进行处理。ActionAction层处理对象是Trigger触发后计算的用户名单,可以给名单里的用户发Push,发权益或者其他定制逻辑。Action本身是标准化、可插拔的组件,业务上可以利用Action组件对用户名单做AB测试,快速实验不同Action策略。接下来我们说一下闲鱼IFTTT详细技术方案,方案如下: 整体技术方案按照业务建模的结构图细化,补充依赖的技术组件。整体流程不再细述,针对流程中重点模块详细说明。 3.1、场景快速接入设计场景快速接入的目的是让业务对接入闲鱼IFTTT无感知,因为在最开始的设计中,场景接入是准备通过在业务逻辑里增加AOP切面,将业务数据和场景上报。但因为这种方式对业务本身有一定侵入,增加业务执行的RT而且不够灵活,最终被否决。 而现在的场景快速接入方案解决了这些问题,通过SLS接入所有应用的海量网络请求日志,记录请求的URL、参数和响应;将SLS作为Blink流计算任务的数据源;根据diamond动态下发的规则实时筛选网络请求URL和参数,把数据按照指定格式组装后上报给Channel层。 场景快速接入方案将业务逻辑与场景接入解耦,支持快速接入,灵活变更且延迟低,是针对大数据场景接入的高性能解决方案。 3.2、计算用户名单计算用户名单模块采用责任链模式设计,因为在不同Trigger场景中,业务对用户名单的计算和筛选逻辑都是不同的。通过责任链模式,将主流程与业务筛选逻辑解耦,并支持各业务灵活定制筛选逻辑,互不干扰。 3.3、PushActionAction层是闲鱼IFTTT中最重要的一环,会直接触达到用户,Action的逻辑会直接影响用户对平台的直观感受和活跃率。消息Push是Action中最常见的逻辑,更要防止用户被骚扰,PushAction逻辑如下: 敏感人群过滤;疲劳度校验;对发送人群进行AB实验;组装消息;将Action各节点日志同步到SLS,方便检索和排查问题;统计消息发送数据及点击数据,为业务后续决策提供依据;3.3.1、疲劳度疲劳度是防止用户被骚扰的关键,我们针对疲劳度进行了分层设计,分为三层,第一层为用户级别疲劳度,控制一个用户在一个周期内收到消息数量;第二层是业务维度,控制用户在一个周期内收到某个业务的消息数量;第三层是目标级别,控制用户在一个周期内收到同一个发送者消息数量。 在业务维度层面,支持灵活控制多个业务联合疲劳度,保证用户不会被消息过度骚扰。 3.4、用户关系存储用户关系数据是闲鱼IFTTT的基石,它的特点是存储量级大,达到TB级别;而且对存储和查询的性能要求高,TPS和QPS的峰值都在一万以上。经过调研,我们发现集团内部开发的Lindorm可以满足需求。 Lindorm是阿里内部基于Hbase自研的高性能KV存储数据库,对Hbase的性能和稳定性均有一定优化。闲鱼IFTTT采用Lindorm作为用户关系数据存储,经性能测试验证数据读取QPS达到7万,数据存储TPS在10万以上。Lindorm本身性能优异,为闲鱼IFTTT高性能奠定基础。 四、效果验证闲鱼IFTTT自上线以来,已支持关注上新、浏览宝贝降价和租房小区上新等多个业务场景,提供买卖双方实时双向互动能力,平均每天处理关系数据数亿条,处理Trigger量达到上千万,处理Action量达到亿级别,消息点击率较离线push提高1倍以上。 闲鱼IFTTT目前支持的是用户互动场景,后续我们将结合闲鱼自身业务特点,对IFTTT进行更高维度抽象,封装标准Recipe接口,将闲鱼IFTTT打造成提供流程编排、管理能力的服务平台。 在我看来,IFTTT从2010年推出以来,在国外有很大的热度,在互联网和物联网领域都有专门的公司和团队在研发,IFTTT的概念虽然简单,却通过标准化协议满足用户的强需求-让各种互联网产品为用户服务。这其实也给我们互联网从业者一些思考:在新机遇面前,究竟是快速投入比较重要还是抽象标准协议解决一类问题更加有效? 五、名词注解SLS:https://cn.aliyun.com/product/slsDiamond:阿里内部研发的持久配置管理中间件;Blink:https://data.aliyun.com/product/sc?spm=5176.10695662.1131226.1.bf495006EWuVABMetaQ:阿里内部研发的分布式、队列模型的消息中间件;Lindorm:阿里内部基于HBase研发的新一代分布式NoSQL数据库,阿里云类似产品:https://www.aliyun.com/product/ots?spm=a2c4g.11174283.cwnn_jpze.59.2f5a15c3NH30me;Tair:阿里内部研发的高性能、分布式、可扩展、高可靠的Key-Value结构存储系统; 本文作者:闲鱼技术-剑辛原文链接 本文为云栖社区原创内容,未经允许不得转载。

June 14, 2019 · 1 min · jiezi

高性能服务器架构思路不仅是思路

在服务器端程序开发领域,性能问题一直是备受关注的重点。业界有大量的框架、组件、类库都是以性能为卖点而广为人知。然而,服务器端程序在性能问题上应该有何种基本思路,这个却很少被这些项目的文档提及。本文正式希望介绍服务器端解决性能问题的基本策略和经典实践,并分为几个部分来说明: 缓存策略的概念和实例2.缓存策略的难点:不同特点的缓存数据的清理机制 3.分布策略的概念和实例 4.分布策略的难点:共享数据安全性与代码复杂度的平衡 缓存缓存策略的概念我们提到服务器端性能问题的时候,往往会混淆不清。因为当我们访问一个服务器时,出现服务卡住不能得到数据,就会认为是“性能问题”。但是实际上这个性能问题可能是有不同的原因,表现出来都是针对客户请求的延迟很长甚至中断。我们来看看这些原因有哪些:第一个是所谓并发数不足,也就是同时请求的客户过多,导致超过容纳能力的客户被拒绝服务,这种情况往往会因为服务器内存耗尽而导致的;第二个是处理延迟过长,也就是有一些客户的请求处理时间已经超过用户可以忍受的长度,这种情况常常表现为CPU占用满额100%。 我们在服务器开发的时候,最常用到的有下面这几种硬件:CPU、内存、磁盘、网卡。其中CPU是代表计算机处理时间的,硬盘的空间一般很大,主要是读写磁盘会带来比较大的处理延迟,而内存、网卡则是受存储、带宽的容量限制的。所以当我们的服务器出现性能问题的时候,就是这几个硬件某一个甚至几个都出现负荷占满的情况。这四个硬件的资源一般可以抽象成两类:一类是时间资源,比如CPU和磁盘读写;一类是空间资源,比如内存和网卡带宽。所以当我们的服务器出现性能问题,有一个最基本的思路,就是——时间空间转换。我们可以举几个例子来说明这个问题。 当我们访问一个WEB的网站的时候,输入的URL地址会被服务器变成对磁盘上某个文件的读取。如果有大量的用户访问这个网站,每次的请求都会造成对磁盘的读操作,可能会让磁盘不堪重负,导致无法即时读取到文件内容。但是如果我们写的程序,会把读取过一次的文件内容,长时间的保存在内存中,当有另外一个对同样文件的读取时,就直接从内存中把数据返回给客户端,就无需去让磁盘读取了。由于用户访问的文件往往很集中,所以大量的请求可能都能从内存中找到保存的副本,这样就能大大提高服务器能承载的访问量了。这种做法,就是用内存的空间,换取了磁盘的读写时间,属于用空间换时间的策略。 举另外一个例子:我们写一个网络游戏的服务器端程序,通过读写数据库来提供玩家资料存档。如果有大量玩家进入这个服务器,必定有很多玩家的数据资料变化,比如升级、获得武器等等,这些通过读写数据库来实现的操作,可能会让数据库进程负荷过重,导致玩家无法即时完成游戏操作。我们会发现游戏中的读操作,大部分都是针是对一些静态数据的,比如游戏中的关卡数据、武器道具的具体信息;而很多写操作,实际上是会覆盖的,比如我的经验值,可能每打一个怪都会增加几十点,但是最后记录的只是最终的一个经验值,而不会记录下打怪的每个过程。所以我们也可以使用时空转换的策略来提供性能:我们可以用内存,把那些游戏中的静态数据,都一次性读取并保存起来,这样每次读这些数据,都和数据库无关了;而玩家的资料数据,则不是每次变化都去写数据库,而是先在内存中保持一个玩家数据的副本,所有的写操作都先去写内存中的结构,然后定期再由服务器主动写回到数据库中,这样可以把多次的写数据库操作变成一次写操作,也能节省很多写数据库的消耗。这种做法也是用空间换时间的策略。 最后说说用时间换空间的例子:假设我们要开发一个企业通讯录的数据存储系统,客户要求我们能保存下通讯录的每次新增、修改、删除操作,也就是这个数据的所有变更历史,以便可以让数据回退到任何一个过去的时间点。那么我们最简单的做法,就是这个数据在任何变化的时候,都拷贝一份副本。但是这样会非常的浪费磁盘空间,因为这个数据本身变化的部分可能只有很小一部分,但是要拷贝的副本可能很大。这种情况下,我们就可以在每次数据变化的时候,都记下一条记录,内容就是数据变化的情况:插入了一条内容是某某的联系方法、删除了一条某某的联系方法……,这样我们记录的数据,仅仅就是变化的部分,而不需要拷贝很多份副本。当我们需要恢复到任何一个时间点的时候,只需要按这些记录依次对数据修改一遍,直到指定的时间点的记录即可。这个恢复的时间可能会有点长,但是却可以大大节省存储空间。这就是用CPU的时间来换磁盘的存储空间的策略。我们现在常见的MySQL InnoDB日志型数据表,以及SVN源代码存储,都是使用这种策略的。 另外,我们的Web服务器,在发送HTML文件内容的时候,往往也会先用ZIP压缩,然后发送给浏览器,浏览器收到后要先解压,然后才能显示,这个也是用服务器和客户端的CPU时间,来换取网络带宽的空间。 在我们的计算机体系中,缓存的思路几乎无处不在,比如我们的CPU里面就有1级缓存、2级缓存,他们就是为了用这些快速的存储空间,换取对内存这种相对比较慢的存储空间的等待时间。我们的显示卡里面也带有大容量的缓存,他们是用来存储显示图形的运算结果的。 缓存的本质,除了让“已经处理过的数据,不需要重复处理”以外,还有“以快速的数据存储读写,代替较慢速的存储读写”的策略。我们在选择缓存策略进行时空转换的时候,必须明确我们要转换的时间和空间是否合理,是否能达到效果。比如早期有一些人会把WEB文件缓存在分布式磁盘上(例如NFS),但是由于通过网络访问磁盘本身就是一个比较慢的操作,而且还会占用可能就不充裕的网络带宽空间,导致性能可能变得更慢。 在设计缓存机制的时候,我们还容易碰到另外一个风险,就是对缓存数据的编程处理问题。如果我们要缓存的数据,并不是完全无需处理直接读写的,而是需要读入内存后,以某种语言的结构体或者对象来处理的,这就需要涉及到“序列化”和“反序列化”的问题。如果我们采用直接拷贝内存的方式来缓存数据,当我们的这些数据需要跨进程、甚至跨语言访问的时候,会出现那些指针、ID、句柄数据的失效。因为在另外一个进程空间里,这些“标记型”的数据都是不存在的。因此我们需要更深入的对数据缓存的方法,我们可能会使用所谓深拷贝的方案,也就是跟着那些指针去找出目标内存的数据,一并拷贝。一些更现代的做法,则是使用所谓序列化方案来解决这个问题,也就是用一些明确定义了的“拷贝方法”来定义一个结构体,然后用户就能明确的知道这个数据会被拷贝,直接取消了指针之类的内存地址数据的存在。比如著名的Protocol Buffer就能很方便的进行内存、磁盘、网络位置的缓存;现在我们常见的JSON,也被一些系统用来作为缓存的数据格式。 但是我们需要注意的是,缓存的数据和我们程序真正要操作的数据,往往是需要进行一些拷贝和运算的,这就是序列化和反序列化的过程,这个过程很快,也有可能很慢。所以我们在选择数据缓存结构的时候,必须要注意其转换时间,否则你缓存的效果可能被这些数据拷贝、转换消耗去很多,严重的甚至比不缓存更差。一般来说,缓存的数据越解决使用时的内存结构,其转换速度就越快,在这点上,Protocol Buffer采用TLV编码,就比不上直接memcpy的一个C结构体,但是比编码成纯文本的XML或者JSON要来的更快。因为编解码的过程往往要进行复杂的查表映射,列表结构等操作。 缓存策略的难点虽然使用缓存思想似乎是一个很简单的事情,但是缓存机制却有一个核心的难点,就是——缓存清理。我们所说的缓存,都是保存一些数据,但是这些数据往往是会变化的,我们要针对这些变化,清理掉保存的“脏”数据,却可能不是那么容易。 首先我们来看看最简单的缓存数据——静态数据。这种数据往往在程序的运行时是不会变化的,比如Web服务器内存中缓存的HTML文件数据,就是这种。事实上,所有的不是由外部用户上传的数据,都属于这种“运行时静态数据”。一般来说,我们对这种数据,可以采用两种建立缓存的方法:一是程序一启动,就一股脑把所有的静态数据从文件或者数据库读入内存;二就是程序启动的时候并不加载静态数据,而是等有用户访问相关数据的时候,才去加载,这也就是所谓lazy load的做法。第一种方法编程比较简单,程序的内存启动后就稳定了,不太容易出现内存漏洞(如果加载的缓存太多,程序在启动后立刻会因内存不足而退出,比较容易发现问题);第二种方法程序启动很快,但要对缓存占用的空间有所限制或者规划,否则如果要缓存的数据太多,可能会耗尽内存,导致在线服务中断。 一般来说,静态数据是不会“脏”的,因为没有用户会去写缓存中的数据。但是在实际工作中,我们的在线服务往往会需要“立刻”变更一些缓存数据。比如在门户网站上发布了一条新闻,我们会希望立刻让所有访问的用户都看到。按最简单的做法,我们一般只要重启一下服务器进程,内存中的缓存就会消失了。对于静态缓存的变化频率非常低的业务,这样是可以的,但是如果是新闻网站,就不能每隔几分钟就重启一下WEB服务器进程,这样会影响大量在线用户的访问。常见的解决这类问题有两种处理策略: 第一种是使用控制命令。简单来说,就是在服务器进程上,开通一个实时的命令端口,我们可以通过网络数据包(如UDP包),或者Linux系统信号(如kill SIGUSR2进程号)之类的手段,发送一个命令消息给服务器进程,让进程开始清理缓存。这种清理可能执行的是最简单的“全部清理”,也有的可以细致一点的,让命令消息中带有“想清理的数据ID”这样的信息,比如我们发送给WEB服务器的清理消息网络包中会带一个字符串URL,表示要清理哪一个HTML文件的缓存。这种做法的好处是清理的操作很精准,可以明确的控制清理的时间和数据。但是缺点就是比较繁琐,手工去编写发送这种命令很烦人,所以一般我们会把清理缓存命令的工作,编写到上传静态数据的工具当中,比如结合到网站的内容发布系统中,一旦编辑提交了一篇新的新闻,发布系统的程序就自动的发送一个清理消息给WEB服务器。 第二种是使用字段判断逻辑。也就是服务器进程,会在每次读取缓存前,根据一些特征数据,快速的判断内存中的缓存和源数据内容,是否有不一致(是否脏)的地方,如果有不一致的地方,就自动清理这条数据的缓存。这种做法会消耗一部分CPU,但是就不需要人工去处理清理缓存的事情,自动化程度很高。现在我们的浏览器和WEB服务器之间,就有用这种机制:检查文件MD5;或者检查文件最后更新时间。具体的做法,就是每次浏览器发起对WEB服务器的请求时,除了发送URL给服务器外,还会发送一个缓存了此URL对应的文件内容的MD5校验串、或者是此文件在服务器上的“最后更新时间”(这个校验串和“最后更新时间”是第一次获的文件时一并从服务器获得的);服务器收到之后,就会把MD5校验串或者最后更新时间,和磁盘上的目标文件进行对比,如果是一致的,说明这个文件没有被修改过(缓存不是“脏”的),可以直接使用缓存。否则就会读取目标文件返回新的内容给浏览器。这种做法对于服务器性能是有一定消耗的,所以如果往往我们还会搭配其他的缓存清理机制来用,比如我们会在设置一个“超时检查”的机制:就是对于所有的缓存清理检查,我们都简单的看看缓存存在的时间是否“超时”了,如果超过了,才进行下一步的检查,这样就不用每次请求都去算MD5或者看最后更新时间了。但是这样就存在“超时”时间内缓存变脏的可能性。 上面说了运行时静态的缓存清理,现在说说运行时变化的缓存数据。在服务器程序运行期间,如果用户和服务器之间的交互,导致了缓存的数据产生了变化,就是所谓“运行时变化缓存”。比如我们玩网络游戏,登录之后的角色数据就会从数据库里读出来,进入服务器的缓存(可能是堆内存或者memcached、共享内存),在我们不断进行游戏操作的时候,对应的角色数据就会产生修改的操作,这种缓存数据就是“运行时变化的缓存”。这种运行时变化的数据,有读和写两个方面的清理问题:由于缓存的数据会变化,如果另外一个进程从数据库读你的角色数据,就会发现和当前游戏里的数据不一致;如果服务器进程突然结束了,你在游戏里升级,或者捡道具的数据可能会从内存缓存中消失,导致你白忙活了半天,这就是没有回写(缓存写操作的清理)导致的问题。这种情况在电子商务领域也很常见,最典型的就是火车票网上购买的系统,火车票数据缓存在内存必须有合适的清理机制,否则让两个买了同一张票就麻烦了,但如果不缓存,大量用户同时抢票,服务器也应对不过来。因此在运行时变化的数据缓存,应该有一些特别的缓存清理策略。 在实际运行业务中,运行变化的数据往往是根据使用用户的增多而增多的,因此首先要考虑的问题,就是缓存空间不够的可能性。我们不太可能把全部数据都放到缓存的空间里,也不可能清理缓存的时候就全部数据一起清理,所以我们一般要对数据进行分割,这种分割的策略常见的有两种:一种是按重要级来分割,一种是按使用部分分割。 先举例说说“按重要级分割”,在网络游戏中,同样是角色的数据,有些数据的变化可能会每次修改都立刻回写到数据库(清理写缓存),其他一些数据的变化会延迟一段时间,甚至有些数据直到角色退出游戏才回写,如玩家的等级变化(升级了),武器装备的获得和消耗,这些玩家非常看重的数据,基本上会立刻回写,这些就是所谓最重要的缓存数据。而玩家的经验值变化、当前HP、MP的变化,就会延迟一段时间才写,因为就算丢失了缓存,玩家也不会太过关注。最后有些比如玩家在房间(地区)里的X/Y坐标,对话聊天的记录,可能会退出时回写,甚至不回写。这个例子说的是“写缓存”的清理,下面说说“读缓存”的按重要级分割清理。 假如我们写一个网店系统,里面容纳了很多产品,这些产品有一些会被用户频繁检索到,比较热销,而另外一些商品则没那么热销。热销的商品的余额、销量、评价都会比较频繁的变化,而滞销的商品则变化很少。所以我们在设计的时候,就应该按照不同商品的访问频繁程度,来决定缓存哪些商品的数据。我们在设计缓存的结构时,就应该构建一个可以统计缓存读写次数的指标,如果有些数据的读写频率过低,或者空闲(没有人读、写缓存)时间超长,缓存应该主动清理掉这些数据,以便其他新的数据能进入缓存。这种策略也叫做“冷热交换”策略。实现“冷热交换”的策略时,关键是要定义一个合理的冷热统计算法。一些固定的指标和算法,往往并不能很好的应对不同硬件、不同网络情况下的变化,所以现在人们普遍会用一些动态的算法,如Redis就采用了5种,他们是: 1.根据过期时间,清理最长时间没用过的 2.根据过期时间,清理即将过期的 3.根据过期时间,任意清理一个 4.无论是否过期,随机清理 5.无论是否过期,根据LRU原则清理:所谓LRU,就是Least Recently Used,最近最久未使用过。这个原则的思想是:如果一个数据在最近一段时间没有被访问到,那么在将来他被访问的可能性也很小。LRU是在操作系统中很常见的一种原则,比如内存的页面置换算法(也包括FIFO,LFU等),对于LRU的实现,还是非常有技巧的,但是本文就不详细去说明如何实现,留待大家上网搜索“LRU”关键字学习。 数据缓存的清理策略其实远不止上面所说的这些,要用好缓存这个武器,就要仔细研究需要缓存的数据特征,他们的读写分布,数据之中的差别。然后最大化的利用业务领域的知识,来设计最合理的缓存清理策略。这个世界上不存在万能的优化缓存清理策略,只存在针对业务领域最优化的策略,这需要我们程序员深入理解业务领域,去发现数据背后的规律。 分布分布策略的概念任何的服务器的性能都是有极限的,面对海量的互联网访问需求,是不可能单靠一台服务器或者一个CPU来承担的。所以我们一般都会在运行时架构设计之初,就考虑如何能利用多个CPU、多台服务器来分担负载,这就是所谓分布的策略。分布式的服务器概念很简单,但是实现起来却比较复杂。因为我们写的程序,往往都是以一个CPU,一块内存为基础来设计的,所以要让多个程序同时运行,并且协调运作,这需要更多的底层工作。 首先出现能支持分布式概念的技术是多进程。在DOS时代,计算机在一个时间内只能运行一个程序,如果你想一边写程序,同时一边听mp3,都是不可能的。但是,在WIN95操作系统下,你就可以同时开多个窗口,背后就是同时在运行多个程序。在Unix和后来的Linux操作系统里面,都普遍支持了多进程的技术。所谓的多进程,就是操作系统可以同时运行我们编写的多个程序,每个程序运行的时候,都好像自己独占着CPU和内存一样。在计算机只有一个CPU的时候,实际上计算机会分时复用的运行多个进程,CPU在多个进程之间切换。但是如果这个计算机有多个CPU或者多个CPU核,则会真正的有几个进程同时运行。所以进程就好像一个操作系统提供的运行时“程序盒子”,可以用来在运行时,容纳任何我们想运行的程序。当我们掌握了操作系统的多进程技术后,我们就可以把服务器上的运行任务,分为多个部分,然后分别写到不同的程序里,利用上多CPU或者多核,甚至是多个服务器的CPU一起来承担负载。 这种划分多个进程的架构,一般会有两种策略:一种是按功能来划分,比如负责网络处理的一个进程,负责数据库处理的一个进程,负责计算某个业务逻辑的一个进程。另外一种策略是每个进程都是同样的功能,只是分担不同的运算任务而已。使用第一种策略的系统,运行的时候,直接根据操作系统提供的诊断工具,就能直观的监测到每个功能模块的性能消耗,因为操作系统提供进程盒子的同时,也能提供对进程的全方位的监测,比如CPU占用、内存消耗、磁盘和网络I/O等等。但是这种策略的运维部署会稍微复杂一点,因为任何一个进程没有启动,或者和其他进程的通信地址没配置好,都可能导致整个系统无法运作;而第二种分布策略,由于每个进程都是一样的,这样的安装部署就非常简单,性能不够就多找几个机器,多启动几个进程就完成了,这就是所谓的平行扩展。 现在比较复杂的分布式系统,会结合这两种策略,也就是说系统既按一些功能划分出不同的具体功能进程,而这些进程又是可以平行扩展的。当然这样的系统在开发和运维上的复杂度,都是比单独使用“按功能划分”和“平行划分”要更高的。由于要管理大量的进程,传统的依靠配置文件来配置整个集群的做法,会显得越来越不实用:这些运行中的进程,可能和其他很多进程产生通信关系,当其中一个进程变更通信地址时,势必影响所有其他进程的配置。所以我们需要集中的管理所有进程的通信地址,当有变化的时候,只需要修改一个地方。在大量进程构建的集群中,我们还会碰到容灾和扩容的问题:当集群中某个服务器出现故障,可能会有一些进程消失;而当我们需要增加集群的承载能力时,我们又需要增加新的服务器以及进程。这些工作在长期运行的服务器系统中,会是比较常见的任务,如果整个分布系统有一个运行中的中心进程,能自动化的监测所有的进程状态,一旦有进程加入或者退出集群,都能即时的修改所有其他进程的配置,这就形成了一套动态的多进程管理系统。开源的ZooKeeper给我们提供了一个可以充当这种动态集群中心的实现方案。由于ZooKeeper本身是可以平行扩展的,所以它自己也是具备一定容灾能力的。现在越来越多的分布式系统都开始使用以ZooKeeper为集群中心的动态进程管理策略了。 在调用多进程服务的策略上,我们也会有一定的策略选择,其中最著名的策略有三个:一个是动态负载均衡策略;一个是读写分离策略;一个是一致性哈希策略。动态负载均衡策略,一般会搜集多个进程的服务状态,然后挑选一个负载最轻的进程来分发服务,这种策略对于比较同质化的进程是比较合适的。读写分离策略则是关注对持久化数据的性能,比如对数据库的操作,我们会提供一批进程专门用于提供读数据的服务,而另外一个(或多个)进程用于写数据的服务,这些写数据的进程都会每次写多份拷贝到“读服务进程”的数据区(可能就是单独的数据库),这样在对外提供服务的时候,就可以提供更多的硬件资源。一致性哈希策略是针对任何一个任务,看看这个任务所涉及读写的数据,是属于哪一片的,是否有某种可以缓存的特征,然后按这个数据的ID或者特征值,进行“一致性哈希”的计算,分担给对应的处理进程。这种进程调用策略,能非常的利用上进程内的缓存(如果存在),比如我们的一个在线游戏,由100个进程承担服务,那么我们就可以把游戏玩家的ID,作为一致性哈希的数据ID,作为进程调用的KEY,如果目标服务进程有缓存游戏玩家的数据,那么所有这个玩家的操作请求,都会被转到这个目标服务进程上,缓存的命中率大大提高。而使用“一致性哈希”,而不是其他哈希算法,或者取模算法,主要是考虑到,如果服务进程有一部分因故障消失,剩下的服务进程的缓存依然可以有效,而不会整个集群所有进程的缓存都失效。具体有兴趣的读者可以搜索“一致性哈希”一探究竟。 以多进程利用大量的服务器,以及服务器上的多个CPU核心,是一个非常有效的手段。但是使用多进程带来的额外的编程复杂度的问题。一般来说我们认为最好是每个CPU核心一个进程,这样能最好的利用硬件。如果同时运行的进程过多,操作系统会消耗很多CPU时间在不同进程的切换过程上。但是,我们早期所获得的很多API都是阻塞的,比如文件I/O,网络读写,数据库操作等。如果我们只用有限的进程来执行带这些阻塞操作的程序,那么CPU会大量被浪费,因为阻塞的API会让有限的这些进程停着等待结果。那么,如果我们希望能处理更多的任务,就必须要启动更多的进程,以便充分利用那些阻塞的时间,但是由于进程是操作系统提供的“盒子”,这个盒子比较大,切换耗费的时间也比较多,所以大量并行的进程反而会无谓的消耗服务器资源。加上进程之间的内存一般是隔离的,进程间如果要交换一些数据,往往需要使用一些操作系统提供的工具,比如网络socket,这些都会额外消耗服务器性能。因此,我们需要一种切换代价更少,通信方式更便捷,编程方法更简单的并行技术,这个时候,多线程技术出现了。 多线程的特点是切换代价少,可以同时访问内存。我们可以在编程的时候,任意让某个函数放入新的线程去执行,这个函数的参数可以是任何的变量或指针。如果我们希望和这些运行时的线程通信,只要读、写这些指针指向的变量即可。在需要大量阻塞操作的时候,我们可以启动大量的线程,这样就能较好的利用CPU的空闲时间;线程的切换代价比进程低得多,所以我们能利用的CPU也会多很多。线程是一个比进程更小的“程序盒子”,他可以放入某一个函数调用,而不是一个完整的程序。一般来说,如果多个线程只是在一个进程里面运行,那其实是没有利用到多核CPU的并行好处的,仅仅是利用了单个空闲的CPU核心。但是,在JAVA和C#这类带虚拟机的语言中,多线程的实现底层,会根据具体的操作系统的任务调度单位(比如进程),尽量让线程也成为操作系统可以调度的单位,从而利用上多个CPU核心。比如Linux2.6之后,提供了NPTL的内核线程模型,JVM就提供了JAVA线程到NPTL内核线程的映射,从而利用上多核CPU。而Windows系统中,据说本身线程就是系统的最小调度单位,所以多线程也是利用上多核CPU的。所以我们在使用JAVAC#编程的时候,多线程往往已经同时具备了多进程利用多核CPU、以及切换开销低的两个好处。 早期的一些网络聊天室服务,结合了多线程和多进程使用的例子。一开始程序会启动多个广播聊天的进程,每个进程都代表一个房间;每个用户连接到聊天室,就为他启动一个线程,这个线程会阻塞的读取用户的输入流。这种模型在使用阻塞API的环境下,非常简单,但也非常有效。 当我们在广泛使用多线程的时候,我们发现,尽管多线程有很多优点,但是依然会有明显的两个缺点:一个内存占用比较大且不太可控;第二个是多个线程对于用一个数据使用时,需要考虑复杂的“锁”问题。由于多线程是基于对一个函数调用的并行运行,这个函数里面可能会调用很多个子函数,每调用一层子函数,就会要在栈上占用新的内存,大量线程同时在运行的时候,就会同时存在大量的栈,这些栈加在一起,可能会形成很大的内存占用。并且,我们编写服务器端程序,往往希望资源占用尽量可控,而不是动态变化太大,因为你不知道什么时候会因为内存用完而当机,在多线程的程序中,由于程序运行的内容导致栈的伸缩幅度可能很大,有可能超出我们预期的内存占用,导致服务的故障。而对于内存的“锁”问题,一直是多线程中复杂的课题,很多多线程工具库,都推出了大量的“无锁”容器,或者“线程安全”的容器,并且还大量设计了很多协调线程运作的类库。但是这些复杂的工具,无疑都是证明了多线程对于内存使用上的问题。 由于多线程还是有一定的缺点,所以很多程序员想到了一个釜底抽薪的方法:使用多线程往往是因为阻塞式API的存在,比如一个read()操作会一直停止当前线程,那么我们能不能让这些操作变成不阻塞呢?——selector/epoll就是Linux退出的非阻塞式API。如果我们使用了非阻塞的操作函数,那么我们也无需用多线程来并发的等待阻塞结果。我们只需要用一个线程,循环的检查操作的状态,如果有结果就处理,无结果就继续循环。这种程序的结果往往会有一个大的死循环,称为主循环。在主循环体内,程序员可以安排每个操作事件、每个逻辑状态的处理逻辑。这样CPU既无需在多线程间切换,也无需处理复杂的并行数据锁的问题——因为只有一个线程在运行。这种就是被称为“并发”的方案。 实际上计算机底层早就有使用并发的策略,我们知道计算机对于外部设备(比如磁盘、网卡、显卡、声卡、键盘、鼠标),都使用了一种叫“中断”的技术,早期的电脑使用者可能还被要求配置IRQ号。这个中断技术的特点,就是CPU不会阻塞的一直停在等待外部设备数据的状态,而是外部数据准备好后,给CPU发一个“中断信号”,让CPU转去处理这些数据。非阻塞的编程实际上也是类似这种行为,CPU不会一直阻塞的等待某些I/O的API调用,而是先处理其他逻辑,然后每次主循环去主动检查一下这些I/O操作的状态。 多线程和异步的例子,最著名就是Web服务器领域的Apache和Nginx的模型。Apache是多进程/多线程模型的,它会在启动的时候启动一批进程,作为进程池,当用户请求到来的时候,从进程池中分配处理进程给具体的用户请求,这样可以节省多进程/线程的创建和销毁开销,但是如果同时有大量的请求过来,还是需要消耗比较高的进程/线程切换。而Nginx则是采用epoll技术,这种非阻塞的做法,可以让一个进程同时处理大量的并发请求,而无需反复切换。对于大量的用户访问场景下,apache会存在大量的进程,而nginx则可以仅用有限的进程(比如按CPU核心数来启动),这样就会比apache节省了不少“进程切换”的消耗,所以其并发性能会更好。 在现代服务器端软件中,nginx这种模型的运维管理会更简单,性能消耗也会稍微更小一点,所以成为最流行的进程架构。但是这种好处,会付出一些另外的代价:非阻塞代码在编程的复杂度变大。 分布式编程复杂度以前我们的代码,从上往下执行,每一行都会占用一定的CPU时间,这些代码的直接顺序,也是和编写的顺序基本一致,任何一行代码,都是唯一时刻的执行任务。当我们在编写分布式程序的时候,我们的代码将不再好像那些单进程、单线程的程序一样简单。我们要把同时运行的不同代码,在同一段代码中编写。就好像我们要把整个交响乐团的每个乐器的乐谱,全部写到一张纸上。为了解决这种编程的复杂度,业界发展出了多种编码形式。 在多进程的编码模型上,fork()函数可以说一个非常典型的代表。在一段代码中,fork()调用之后的部分,可能会被新的进程中执行。要区分当前代码的所在进程,要靠fork()的返回值变量。这种做法,等于把多个进程的代码都合并到一块,然后通过某些变量作为标志来划分。这样的写法,对于不同进程代码大部份相同的“同质进程”来说,还是比较方便的,最怕就是有大量的不同逻辑要用不同的进程来处理,这种情况下,我们就只能自己通过规范fork()附近的代码,来控制混乱的局面。比较典型的是把fork()附近的代码弄成一个类似分发器(dispatcher)的形式,把不同功能的代码放到不同的函数中,以fork之前的标记变量来决定如何调用。 ...

June 12, 2019 · 1 min · jiezi

TableStore-海量结构化数据分层存储方案

前言表格存储是阿里云自研分布式存储系统,可以用来存储海量结构化、半结构化的数据。表格存储支持高性能和容量型两种实例类型。高性能使用SSD的存储介质,针对读多写多的场景都有较好的访问延时。容量型使用的是SSD和SATA混合的存储介质。对写多的场景,性能接近高性能,读方面,如果遇到冷数据产生读SATA盘的话,延时会比高性能上涨一个量级。在海量数据存储场景下,例如时序场景,我们会希望最新的数据可以支持高性能查询,较早的数据的读写频次都会低很多。这时候一个基于表格存储高性能和容量型存储分层的需求就产生了。 方案细节表格存储近期对外正式发布的全增量一体的通道服务(参考文档),通道服务基于表格存储数据接口之上的全增量一体化服务。通道服务为用户提供了增量、全量、增量加全量三种类型的分布式数据实时消费通道。有了通道服务,我们可以很方便的构建从高性能实例下的表到容量型表之间的实时数据同步,进而可以在高性能表上使用表格存储的特性数据生命周期(参考文档),根据业务需求设置一个合理的TTL。总体来说就可以构建一个如下图所示的架构: 整个数据的流动过程如下: 业务写入端直接写入高性能实例高性能实例中的数据通过通道服务同步至容量型高性能实例中的老数据自动过期,减少存储量占用用户查询请求根据时序查询条件,判断是否是近期数据 近期数据查询进入高性能,毫秒级别返回较早数据查询进入容量型,几十毫秒后返回代码和操作流程:在高性能实例上根据业务主键需求创建数据表,并设置合理的数据TTL,然后在容量型下创建相同的schema的表用来持久化存储所有数据。 然后在通道页面创建一个全增量类型的通道: 通过控制台可以简单清晰的查看到同步的状态,并发,进度等信息: 下面贴一下通过Tunnel进行复制同样schema表TableStore表的Sample代码: func main () { //高性能实例的信息 tunnelClient := tunnel.NewTunnelClient("", "", "", "") //容量型实例的信息 client := tablestore.NewClient("", "", "", "") //配置callback到SimpleProcessFactory,配置消费端TunnelWorkerConfig workConfig := &tunnel.TunnelWorkerConfig{ ProcessorFactory: &tunnel.SimpleProcessFactory{ ProcessFunc: replicateDataFunc, CustomValue: client, }, } //使用TunnelDaemon持续消费指定tunnel daemon := tunnel.NewTunnelDaemon(tunnelClient, "", workConfig) err := daemon.Run() if err != nil { fmt.Println("failed to start tunnel daemon with error:", err) }}func replicateDataFunc(ctx *tunnel.ChannelContext, records []*tunnel.Record) error { client := ctx.CustomValue.(*tablestore.TableStoreClient) fmt.Println(client) for _, rec := range records { fmt.Println("tunnel record detail:", rec.String()) updateRowRequest := new(tablestore.UpdateRowRequest) updateRowRequest.UpdateRowChange = new(tablestore.UpdateRowChange) updateRowRequest.UpdateRowChange.TableName = "coldtable" updateRowRequest.UpdateRowChange.PrimaryKey = new(tablestore.PrimaryKey) updateRowRequest.UpdateRowChange.SetCondition(tablestore.RowExistenceExpectation_IGNORE) for _, pk := range rec.PrimaryKey.PrimaryKeys { updateRowRequest.UpdateRowChange.PrimaryKey.AddPrimaryKeyColumn(pk.ColumnName, pk.Value) } for _, col := range rec.Columns { if col.Type == tunnel.RCT_Put { updateRowRequest.UpdateRowChange.PutColumn(*col.Name, col.Value) } else if col.Type == tunnel.RCT_DeleteOneVersion { updateRowRequest.UpdateRowChange.DeleteColumnWithTimestamp(*col.Name, *col.Timestamp) } else { updateRowRequest.UpdateRowChange.DeleteColumn(*col.Name) } } _, err := client.UpdateRow(updateRowRequest) if err != nil { fmt.Println("hit error when put record to cold data", err) } } fmt.Println("a round of records consumption finished") return nil}总结通过通道服务,存储在表格存储中的结构化,半结构化数据可以实时流出,进行加工,萃取,计算或进行同步。如果是想进一步降低冷数据的存储成本,可以参考这篇文章把表格存储的数据备份到OSS归档存储。 ...

June 5, 2019 · 1 min · jiezi

IP应用加速 – DCDN迈入全栈新篇章

4月11日,第七届"亚太内容分发大会"暨CDN峰会国际论坛中,阿里云资深技术专家姚伟斌发布了DCDN子产品IP应用加速(IPA)。IPA是基于阿里云CDN本身的资源优化,对传输层(TCP&UDP)协议进行全栈能力提升,同时利用就近接入、智能路由、传输协议优化,以及多种负载均衡技术,实现更高效、更安全、更快速、更便捷的动态加速产品。通常全球内容传输会存在一些痛点,比如:偏远用户、长尾用户访问质量差;对跨运营商,跨国的覆盖要求;游戏、RTC等行业对可靠性、实时性要求很高;电商、金融等行业对安全性要求更高;失败率高等等,IP应用加速的出现,能很好的解决这些问题。优质的内容分发加速最基本的指标是可靠性,阿里云通过覆盖全球的2500个节点,利用超过99%精度的IP数据,并支持TCP和UDP自适应接入实现智能调度同时自研协议栈、多路径传输、动态选路、DDoS防御和全链路加密提供安全、可靠的传输链路。IPA功能优势及架构覆盖更多场景:除了七层外,还对四层、三层网络协议进行支持,全协议栈加速通道,满足更多用户需求和业务场景。更高可靠性:有效解决偏远地区、跨境传输的互联互通问题,降低错误率提供更低延时加速体验降低成本:大幅度减少机器及专线成本,节省预算。安全防护:抗攻击、流量清洗,满足高安全性的业务场景需求以下为整体架构图,包括边缘智能就近接入,节点间实时探测,动态选路,节点间高性能自研协议栈,源站自动选择。针对更高性能的传输需求,阿里云自研的高性能私有传输协议,实现数据多路径传输,改造TCP协议栈提升整个传输效率,加速整个数据传输的可靠性和实时性。同时对内部链路,也支持秒级智能路由切换功能,极大降低数据传输时候应对丢包的可能性。下图是线上实测的数据,相对于TCP协议来说,传输的效率会提升20%以上。IPA适用场景直播互动:弹幕分发、礼物分发、登录连接、评论分享、聊天室消息…游戏行业:游戏互动指令、游戏语音传输、TCP数据接口、UDP内容交互…在线教育:师生音视频互动、文件分享、即时消息、屏幕共享…办公系统:SSL VPN、远程桌面、移动办公APP、邮箱系统、OA…云服务同步:数据中心同步、云ERP、云CRM、远程登录系统…金融行业:手机银行、网银支付、在线交易、股票买卖…在接入方式上,IPA只需要用户提交一个域名即可接入,仅仅1分钟一键就可以开启四层加速的功能,有效降低原来开专线、买服务器等业务加速的复杂度,缩短业务上线时间。应用案例办公通讯软件这个场景下的最大痛点是偏远地区消息不稳定以及海外通信质量差,会出现失败率高的情况,IPA通过下图中的优化架构,从HTTPDNS接入,在节点内部通过ACL有效保证端口的高可靠性,全球访问速度提升超过50%。互动直播应用互动直播中发弹幕、送礼物的场景,对交流的实时性要求非常高,经常会出现登录与加速缓慢,互动体验差等问题。阿里云IPA架构支持客户端与中心服务器之间更有效的交流,同时覆盖了东南亚以及全国各地的地区,最终实现评论、分享延时降低20%以上。办公ERP系统办公ERP系统的痛点是数据传输延迟高,不稳定,表单查询成功率低等问题,导致协同办公效率低下。通过IPA对于超大文件的传输优化,实现传输速率提升30%以上,可用性提升50%。金融行业金融交易的展示不实时,用户的交易就无法保障,针对海外交易延时偏高,价格变动频繁,交易过程失败率高,对于安全性要求更高等问题,因此,阿里云针对针对链路传输加密,对源站保障负载均衡,最终整体延迟降低超过了80%。谈到IP应用加速的未来规划,姚伟斌说:未来IPA会提供三层、四层、七层全栈加速能力,支持数十万海量边缘节点接入,真正实现端-边-云的Overlay边缘传输网络,并尝试与生态硬件集成,为5G时代的边缘智能网络提供基础。本文作者:樰篱阅读原文本文为云栖社区原创内容,未经允许不得转载。

April 12, 2019 · 1 min · jiezi

细说双Buffer缓冲池

前言缓冲机制是对数据持久化的延迟,减少不必要的IO,提高数据落盘的效率。本文将会详细探讨拥有双Buffer的缓冲池(下文统称TwinsBufferPool)是如何实现的,读者可以依此推广,得到N-Buffer的实现原理。在此篇文章中,缓冲区(Buffer)和缓冲池(BufferPool)是两个重要的概念,很明显,两者构成了一个包含与被包含的关系,一个缓冲池内可以有一个或者多个缓冲区协同工作,缓冲池中的所有缓冲区被组织成了一个环形队列,一前一后的两个缓冲区可以互相替换角色。当然,在整个过程中,还会有其他辅助工具的出现,在下文都会逐一阐述。一、设计要点1、可扩展性。毫无疑问,可扩展性是对一个设计良好的软件的一项基本要求,而一个软件的可扩展的地方通常是有很多处的,这在某种程度上会依赖于编程者的经验,如果仅仅局限于产品需求,可能会严重限制了软件的可扩展性。缓冲池是一种相对通用的中间件,扩展点相对比较多,比如:缓冲区数量可指定,线程安全与否,缓冲区阈值调配等等。2、易用性。设计出来的中间件应该是对用户友好的,使用过程中不会有繁琐的配置,奇形怪状的API,更不能有诸多不必要的Dependencies,如果能做到代码无侵入性,那就非常完美了。基于这个要求,TwinsBufferPool做成了一个Spring Boot Starter的形式,加入到项目里的dependencies中即可开启使用。3、稳定性。这就是衡量一个中间件好坏的重要KPI之一,从外观上看,同样是一艘船,破了一个洞和完好无缺将会是一个致命的区别,用户期望自己搭上了一艘完整的船,以便能航行万里而无忧。4、高效性。说到稳定性,那就不得不说高效了,如果能帮助用户又好又快的解决问题,无疑是最完美的结果。关于TwinsBufferPool的稳定性和高效性两个指标,会在文中附上jemeter的压测结果,并加以说明。二、设计方案这一小节将会给出TwinsBufferPool完整的设计方案,我们先从配置说起。每个参数都会提供默认值,所以不做任何配置也是允许的。如下是目前TwinsBufferPool能提供的配置参数(yml):buffer: capacity: 2000 threshold: 0.5 allow-duplicate: true pool: enable-temporary-storage: true buffer-time-in-seconds: 120下面附上参数说明表:以上参数比较浅显易懂,这里重点解释enable-temporary-storage和buffer-time-in-seconds这两个参数。根据参数说明,很明显可以感受到,这两个参数是为了预防突发情况,导致数据丢失。因为缓冲区都是基于内存的设计的,这就意味着缓冲的数据随时处于一种服务重启,或者服务宕机的高风险环境中,因此,才会有这两个参数的诞生。因为TwinsBufferPool良好的接口设计,对于以上两个参数的实现机制也是高度可扩展的。TwinsBufferPool默认的是基于Redis的实现,用户也可以用MongoDB,MySQL,FileSystem等方式实现。由此又会衍生出另外一个问题,由于各种异常情况,导致临时存储层遗留了一定量的数据,需要在下次启动的时候,恢复这一部分的数据。总而言之,数据都是通过flush动作最终持久化到磁盘上。因为大多数实际业务场景对于缓冲池的并发量是有一定要求的,所以默认就采用了线程安全的实现策略,受到JDK中ThreadPool的启发,缓冲池也具备了自身状态管理的机制。如下列出了缓冲池所有可能存在的状态,以及各个状态的流转。/** * 缓冲池暂未就绪 /private static final int ST_NOT_READY = 1;/* * 缓冲池初始化完毕,处于启动状态 /private static final int ST_STARTED = 2;/* * 如果安全关闭缓冲池,会立即进入此状态 /private static final int ST_SHUTTING_DOWN = 3;/* * 缓冲池已关闭 /private static final int ST_SHUTDOWN = 4;/* * 正在进行数据恢复 */private static final int ST_RECOVERING = 5;通过上述的一番分析,设计的方案也呼之欲出了,下面给出主要的接口设计与实现。通过以上的讲解,也不难理解BufferPool定义的接口。缓冲池的整个生命周期,以及内部的一些运作机制都得以体现。值得注意的是,在设计上,将缓冲池和存储层做了逻辑分离,使得扩展性进一步得到增强。存储相关的接口包含了一些简单的CURD,目前默认是用Redis作为临时存储层,MongoDB作为永久存储层,用户可以根据需要实现其他的存储方式。下图展现的是TwinsBufferPool的实现方式,DataBuffer是缓冲区,必须依赖的基础元素。因为设计的是环形队列,所以依赖了CycleQueue,这个环形队列的interface也是自定义的,在JDK中没有找到比较合适的实现。值得注意的是,BufferPool接口定义是灵活可扩展的,TwinsBufferPool只是提供了一种基于环形队列的实现方式,用户也可以自行设计,使用另外一种数据结构来支撑缓冲池的运作。三、压测报告使用的是个人的PC电脑,机器的配置如下:处理器:i5-7400 CPU 3.00GHZ 四核内存:8.00GB操作系统:Windows10 64位 基于x64的处理器运行环境如下:jdk 1.8.0_144SpringBoot_2.1.0,内置Tomcat9.0Redis_v4.0.1MongoDB_v3.4.7测试工具:jemeter_v5.1总共测试了四组参数,每组参数主要是针对最大容量,阈值和最大缓冲时间三个参数来做调整。第一组:buffer: capacity: 1000 threshold: 0.8 pool: buffer-time-in-seconds: 60第二组:buffer: capacity: 5000 threshold: 0.8 pool: buffer-time-in-seconds: 60第三组buffer: capacity: 5000 threshold: 0.8 pool: buffer-time-in-seconds: 300第四组buffer: capacity: 10000 threshold: 0.8 pool: buffer-time-in-seconds: 300总共采集了9个指标:CPU占用率,堆内存/M,线程数,错误率,吞吐量/sec,最长响应时间/ms,最短响应时间/ms,平均响应时间/ms,数据丢失量。限于篇幅,只展示4个指标:堆内存,数据丢失量,平均响应时间,吞吐量。总体来看,随着每秒并发量的增加,各项指标呈现了不太乐观的趋势,其中最不稳定的是第四组参数,波动较为明显,综合表现最佳的是第二组参数,其次是第三组。数据丢失量是一个比较让人关心的指标,从图中可以得知,在并发量达到4000的时候,开始有数据丢失的现象,而造成这一现象的原因并非是TwinsBufferPool实现代码的Bug,而是请求超时导致的“Connection refused”,因为每个Servlet运行容器都会有超时机制,如果排队请求时间过长,就是直接被拒绝了。因此,看数据丢失量和错误率曲线,这两者是一致的。如果设置成不超时,那么将是零丢失量,零错误率,所带来的代价就是平均响应时间会拉长。因为受限于个人的测试环境,整个测试过程显得不是很严谨,得出来的数据也并不是很完美,不过,我这里提供了一些优化调整的建议:1、硬件环境。正所谓“巧妇难为无米之炊”,如果提供的硬件性能本身就是有限的话,那么,在上面运行的软件也难以得到正常的发挥。2、软件架构。这个想象的空间很大,其中有一种方案我认为未来可以纳入到RoadMap中:多缓冲池的负载均衡。我们可以尝试在一个应用中启用多个缓冲池,通过调度算法,将缓冲数据均匀的分配给各个缓冲池,不至于出现只有一个缓冲池“疲于奔命”的状况,最起码系统的吞吐量会有所提升。3、其他中间件或者工具的辅助,比如加上消息中间件可以起到削峰的作用,各项指标也将会有所改善。4、参数调优。这里的参数指代的不仅仅是缓冲池的参数,还有包括最大连接数,最大线程数,超时时间等诸多外部参数。四、总结本文详细阐述了双Buffer缓冲池的设计原理,以及实现方式,并对TwinsBufferPool实施了压测,也对测试结果进行了一番分析。欢迎关注我的微信订阅号:技术汇。如果想查看完整的测试报告,可在订阅号内回复关键词:测试报告,即可获取到下载链接。如果想深入研究TwinsBufferPool源码的读者,可在订阅号内回复关键词:缓冲池。 ...

March 28, 2019 · 1 min · jiezi

阿里数据库的极致弹性之路

阿里妹导读:数据库从IOE(IBM小机、Oracle商业DB、EMC存储)一路走来,大家都知道数据库是资源重依赖的软件,对服务器的三大件CPU、内存、磁盘几乎都有要求。数据库作为广泛使用的数据存储系统,其SQL请求背后涉及的物理读、逻辑读、排序过滤等消耗了IO和CPU资源,业务SQL不同,执行计划不同,资源消耗就不同,因而不同业务对资源规格的需求也不一样。正因如此,我们更需要抽象规格,更好地让不同资源诉求的数据库实例混跑在相同的物理机上,提升整体利用率。今天,阿里资深技术专家天羽为我们讲述阿里数据库的极致弹性之路。除了日常业务需求,阿里的双11场景,让我们持续思考如何低成本高效率地支持峰值流量,把这些思考变成现实,变成技术竞争力。在大促资源弹性上有这么几个思路:使用公共云标准资源弹性,直接用阿里云的标准资源支撑大促后归还。这个是最直接的想法,但这里的难度是业务需求和云资源在性能、成本上的差距,不要定制化机器。混部能力,存量业务的分类混部、分时混部。使用离线资源支撑大促,既是分类混部,双11零点离线降级,高峰后在线归还资源也是分时复用。快上快下,在有能力使用云、离线资源后,尽量缩短占用周期。碎片化资源,数据库一直是块石头,是一个大块完整的规格。如果把数据库自己的大库变成小库,就可以使用其他业务的碎片化资源,包括公共云上的资源。大促的成本=持有资源X持有周期,更通用的资源(云)、更快的部署(容器化)是缩短持有周期的关键,如何更少地使用资源(使用离线或只扩计算资源),就依赖存储计算分离架构的实施。沿着极致弹性的目标,数据库经历了混合云弹性、容器化弹性、计算存储分离弹性三个阶段,基础架构从高性能ECS混合云、容器化混合云、存储计算分离的公共云和离线混部一步步升级。基本上架构演进就是每年验证一个单元,第二年全网铺开,每年挖个坑然后和团队一起努力爬出来,每次演进需要跨团队背靠背紧密合作,快速拿下目标,这也是阿里最神奇的力量。借助于底层软硬件技术发展,一步步的架构升级使得弹性混部越来越灵活和快速。 一、混合云弹性,高性能ECS应运而生2015年之前,我们的大促弹性叫人肉弹性,也就是大促要搬机器,比如集团用云的机型支撑大促,大促结束后搬机器归还给云。但就在2015年底的一次会议上,李津问能否把数据库跑到ECS上,如果可以,就真正帮助了云产品成熟,当时张瑞和我讨论了一下,在会议上就答复了:我们决定试一下。这个合作非常契合会议主题“挑战不可能——集团技术云计算战区12月月会召集令”。对于数据库跑在虚拟机上,我们判断最大的消耗在IO和网络的虚拟化上,因此如何做到接近本机性能,怎么穿透虚拟化就是一个问题。网络的用户态技术DPDK已经比较成熟,但如何做到足够高的效率,是否offload到硬件来做计算是个问题。文件系统IO的用户态链路有个Intel的SPDK方案,Intel推出后各大厂商还在验证中,还没有规模的应用。我们就在这个时候启动的这个项目,叫高性能ECS。通过和ECS团队紧密合作,最终我们做到了最差场景高性能ECS相比本地盘性能损耗低于10%。2016年在集团通过了日常验证,2017年大促开始大规模用云资源直接弹性。这个项目除了打造高性能ECS产品,更重要的是沉淀了网络和文件IO的纯用户态链路技术,这是一个技术拐点的产生,为阿里后续存储计算分离相关产品的高性能突破打下了基础。二、容器化弹性,提升资源效率随着单机服务器的能力提升,阿里数据库在2011年就开始使用单机多实例的方案,通过Cgroup和文件系统目录、端口的部署隔离,支持单机多实例,把单机资源利用起来。但依然存在如下问题:内存的OOM时有发生存在IO争抢问题多租户混部存在主机账号等安全问题数据库主备机型一致性随着单机部署密度越来越高,社区Docker也开始发展起来,尽管还不成熟,Docker本身依赖Cgroup做资源隔离,解决不了Cgroup的IO争抢或OOM问题,但它通过资源隔离和namespace隔离的结合,尝试对资源规格以及部署做新的定义,因此我们看到了容器化更多的优势:标准化规格,数据库与机型解耦,主备不需要对称。这对规模化运维带来极大的效率。Namespace隔离带来混部能力,资源池统一。不同数据库类型,不同数据库版本随便混。让DB具备与其他应用类型混部的条件。2015年数据库开始验证容器化技术,2016年在日常环境中大量使用。因此在集团统一调度的项目启动后,我们就定下了2016年电商一个交易单元全部容器化支撑大促的目标,承载交易大盘约30%,并顺利完成。2017年数据库就是全网容器化的目标,目前数据库全网容器化比例已经接近100%。容器化除了提升部署弹性效率,更重要的是透明底层资源差异,在没有启动智能调度(通过自动迁移提升利用率)前,仅仅从容器化带来的机器复用和多版本混部,就提升了10个点的利用率,资源池的统一和标准部署模板也加快了资源交付效率。容器化完成了底层各种资源的抽象,标准化了规格,而镜像部署带来了部署上的便利,基于数据库PaaS和统一调度层的通力合作,数据库的弹性变得更加快速灵活,哪里有资源,哪里就能跑起数据库。 三、计算资源极致弹性,存储计算分离架构升级实现了容器化混合云,是不是每年大促使用高性能ECS,容器化部署就可以了呢?其实还是有不足的:数据库弹性需要搬数据,把数据搬到ECS上是非常耗时的工作。 弹性规模太大,如果超过公有云售卖周期,会增加持有成本。因此如何做到更快、更通用的弹性能力,是一个新的技术问题。随着2016年调度的发展,大家考虑机器是不是应该无盘化,是不是应该存储计算分离,从而加快调度效率,而数据库的存储计算分离更是争议很大。数据库的Share Nothing分布式扩展已经深入人心,存储计算分离会不会回到IOE状态?如果IDC是一个数据中心,应用就是计算,DB就是存储,DB自己再做存储计算分离有意义吗?数据是主备双副本的,存储计算分离后变成三副本,存储集群的容量池化能balance掉额外副本的成本吗?为此我开始测算存储计算分离架构在大促场景下的投入产出,我们来看下大促场景,弹性大促时,业务需求计算能力数倍甚至10倍以上扩容,承担大促峰值压力,而磁盘因为存储长期数据,峰值的数据量在整体占比不高,因此磁盘容量基本不需要扩容。在以前本地磁盘跑主备的架构,无法计算、存储分开扩容,大促指标越高,添加标准机器越多,成本浪费越大,因为磁盘是标准数据库机器的主要成本。而存储计算分离的情况下,测算下来,我们看到在较低日常压力下存储计算分离成本是比本地盘高的,但再往上,存储计算分离只需要增加计算,存储集群因为池化后,不只容量池化了,性能也池化了,任何高负载实例的IO都是打散到整个集群分担的,磁盘吞吐和IOPS复用,不需扩性能,成本优势非常明显。磁盘不扩容,只扩计算自然成本低很多。传统的思考是存储集群容量池化的优势,但在大促场景我们更多用到的是性能的池化,突破单机瓶颈,因此我们提出了电商异地多活所有单元存储计算分离,其余业务继续使用本地磁盘进行同城容灾的目标架构。提出这个设想,而这个架构的可行性如何判断?基于一些数字就可以推断,大家知道SSD磁盘的读写响应时间在100-200微秒,而16k的网络传输在10微秒内,因此尽管存储计算分离增加两到三次的网络交互,加上存储软件本身的消耗,整体有机会做到读写延时在 500微秒的范围内。在数据库实例压测中我们发现,随着并发增加,存储集群具备更大的QPS水位上线,这印证了性能池化突破单机瓶颈带来的吞吐提升。数据库团队在2017年开始验证存储计算分离,基于25G的TCP网络实现存储计算分离部署,当年就承担了10%大促流量。我们基于分布式存储做到了700微秒的响应时间,这里内核态和软件栈的消耗较大,为此X-DB也针对性地做了慢IO优化,特别是日志刷盘的优化,开启原子写去掉了double write buffer提升吞吐能力。这个过程中,我们沉淀了存储的资源调度系统,目前已经作为统一调度的组件服务集团业务。我们对当前架构性能不太满意,有了X-DB的慢IO优化、存储计算分离跨网络的IO路径、存储资源调度等技术沉淀,加上阿里巴巴RDMA网络架构的发展,2017下半年数据库开始和盘古团队一起,做端到端全用户态的存储计算分离方案。四、全用户态IO链路的存储计算分离架构落地 从数据库软件X-DB的IO调用开始,就走我们自己研发的用户态文件系统DBFS,DBFS使用盘古的用户态客户端,直接通过RDMA网络访问后端盘古分布式文件系统,整个IO链路完全绕过了内核栈。这里DBFS绕过了内核文件系统,自然也绕过了pagecache,为此DBFS针对数据库场景,实现了更简洁高效的BufferIO机制。因为IO都是跨网络远程访问,因此RDMA起到了重要作用,以下是RDMA与TCP网络在不同包大小下的延时对比,除了延时优势外,RDMA对长尾IO的tail latency能够有效控制,对一个数据库请求涉及多次IO来说,对用户请求的响应时间能够更有效保证。RDMA技术的应用是DB大规模存储计算分离的前提条件,通过我们的数据实测,DBFS+RDMA链路的延时已经和Ext4+本地盘达到相同水平。今年我们首次大规模部署RDMA,如履薄冰。经过多次压测、演练, RDMA配套监控和运维体系建设已经完善起来,我们能够在1分钟内识别服务器网卡或交换机的网络端口故障触发告警,能够故障快速隔离,支持业务流量快速切走,支持集群或单机的网络RDMA向TCP降级切换等等。在我们的切流演练中,从DBFS看到RDMA链路的写延时比TCP降低了一倍。我们在全链路压测中,基于RDMA技术保障了在单个数据库实例接近2GB吞吐下磁盘响应时间稳定在500微秒左右,没有毛刺。盘古分布式存储为了同时支持RDMA、EC压缩、快照等功能,做了大量的设计优化,尤其对写IO做了大量优化,当然也包括RDMA/TCP切流,故障隔离等稳定性方面的工作。作为阿里的存储底盘,其在线服务规模已经非常庞大。整个技术链路讲清楚之后,说一下我们在规模应用中遇到的难题,首先,容器的网络虚拟化Bridge和RDMA天然不兼容,由于容器走Bridge网络模式分配IP,而这个是走内核的。为了应用RDMA,我们必须使用Host网络模式进行容器化,走Host + X-DB + DBFS + RDMA +盘古存储这样的全用户态链路。其次,对于公有云环境,我们通过VPC打通形成混合云环境,因此应用通过VPC访问数据库,而数据库使用物理IP用于RDMA访问盘古以及X-DB内部X-Paxos。这个方案复杂而有效,得益于DBPaaS管控的快速迭代和容器化资源调度的灵活性,这些新技术能够快速落地,在变化中稳步推进。今年年初,我们定下了2018大促的支撑形态,即异地多活的中心机房将计算弹性到大数据的离线资源,单元机房将计算弹性到公共云资源,不搬数据直接弹性扩容,快上快下的大促目标。今年DB全局一盘棋,完成了资源调整,实现了电商各站点的存储计算分离架构升级,并通过X-DB异地多副本架构灵活部署,实现了弹性大促目标。基于底层盘古分布式的共享存储,弹性不需要迁移数据,只需要挂载磁盘,数据库可以像应用一样快速弹性,做到一个集群10分钟完成弹性扩容。同时在全链路压测过程中,对出现性能瓶颈的业务,我们可以边压边弹,快速弹到更大的规格上。基于快速弹性的能力,今年DB所有站点的大促扩容都在三天内完成,这在以前是不可能实现的,这就是存计分离的架构带来的效率。最后,感谢阿里内部通力合作的盘古、网络、调度、IDC等团队,正是大家的支持让阿里数据库的基础架构才能不断升级,不断提升效率和成本的竞争力。数据库存储计算分离的架构升级,大大节约了大促资源成本。目前我们的弹性能力正在日常化,通过数据预测,自动触发弹性扩容,我们的目标是让单机容量问题导致故障成为历史。 接下来我们平台将向智能化发展,对于数据库来说,只有基础架构足够强大,足够快速,灵活,弹性,智能化才能有效发挥。本文作者:天羽 阅读原文本文来自云栖社区合作伙伴“阿里技术”,如需转载请联系原作者。

December 11, 2018 · 1 min · jiezi

蚂蚁金融科技全面开放战略背后的技术布局

导读:蚂蚁金融科技全面开放战略的公布,意味着蚂蚁金融科技正式进入全新的3.0时代。蚂蚁金融科技15年来的演进,在其发展史上不断留下了技术里程碑,同时,也缔造出一个又一个的业界“奇迹”。本文将深度揭秘蚂蚁金服的技术战略及布局。11月7日,第五届世界互联网大会在浙江乌镇开幕。当天下午,代表着行业最高水准的“世界互联网领先科技成果”发布,蚂蚁金服自主可控的金融级商用区块链平台等十余项先进技术获得此项殊荣。11月8日,世界互联网大会上由中国人民银行科技司主办的“金融科技与信用社会建设”主题论坛,蚂蚁金服宣布基于网络黑灰产防控治理的“天朗计划”全面升级,将蚂蚁风险大脑对传销、非法集资、金融诈骗等金融风险防控融入其中,同时,蚂蚁风险大脑也将会全面赋能合作伙伴,为其业务发展保驾护航,为投资者和消费者提供一个天朗气清的网络空间。而在同期举行的 “互联网之光”博览会上,蚂蚁金服不仅展示了15年来的技术演进之路,而且重点展示了区块链技术和蚂蚁风险大脑等相关产品及解决方案。蚂蚁金服15年技术演进之路经过15年的发展,蚂蚁金服已经成长为中国最重要的金融科技平台。除了支付、信贷、保险、理财、征信等众多业务,在金融技术的研发、投入及开放上,也已深耕不辍了多年。最初的蚂蚁金融云逐渐演变,在积累了众多云计算能力和技术组件的基础上,早已超越了传统金融云的概念,而囊括了云计算、大数据、AI、IoT、区块链等一整套技术体系。我们势必需要重新认识蚂蚁金服,将它的立体与多维展现出来,让金融科技的价值被真正重视!全面开放:数字金融技术整体解决方案当下,以支付宝为代表的蚂蚁金服的产品从一开始就要接受来自于网上的各种检验、钓鱼、攻击、窃取。面对一个开放的系统,没有办法关起门来,需要去研发各种技术,这对技术能力是非常大的考验。3年前,蚂蚁金服启动了“互联网推进器”计划,该计划表明,蚂蚁金服将在5年内助力超过1000家金融机构向新金融转型升级,在平台、数据和技术等方面实施能力全面对外开放。从2015年蚂蚁金融云发布到2016年GeaBase在支付场景上线,从2017年OceanBase 三地五中心集群部署到2018年“蚂蚁风险大脑”上线,蚂蚁金融科技开放一直在往纵深方向发展。到了今天,蚂蚁金服已经逐渐形成了“点线面”相结合的技术解决方案体系,包含了海量金融交易技术、金融智能技术、新一代金融交互技术、金融安全、区块链、综合技术等。在蚂蚁金融科技的大版图上,强调“技术开放”,而不是“技术输出”,或许这不仅仅是喊的口号不同,更是因为两者所导致的结果是真正差异化的:“开放”更具开源精神,它助推着金融科技的融合与创新,让新金融变成了“更好的金融”。在此前云栖ATEC主论坛上,蚂蚁金服副CTO胡喜就宣布,蚂蚁金服的金融科技正式全面开放,为行业提供完整的数字金融解决方案。包括容灾系统在内的多项核心技术和解决方案,如金融安全、蚂蚁风险大脑、区块链等都将对合作伙伴开放。五大关键技术详解:蚂蚁金服的“完整答卷”除了让金融机构摆脱传统IT架构的束缚外,蚂蚁金服也成就了自己世界级的技术能力。在多条重要技术主线上,无数的金融场景都能被一一对应,蚂蚁金服也由此不断进入“新领地”,在技术前沿展开探索。因此,主要梳理的技术主线有如下5条:海量金融交易技术交易技术是支付宝创造“人间奇迹”的起点。2017年的“双11”,支付宝凭借多项新纪录成为当天的主角:11秒钟破亿,28秒钟破10亿,3分01秒破100亿,6分05秒钟破200亿。根据支付宝官方数据,第5分22秒,双11的支付峰值达到25.6万笔/秒,同时蚂蚁金服自主研发的数据库处理峰值达到4200万次/秒,双双创下新纪录。而海量金融交易技术的背后,其实是分布式架构所带来的创新优势,敏捷迭代、容灾安全、弹性伸缩构成了分布式架构转型升级的三大驱动力。其中,OceanBase分布式数据库、SOFA ware分布式中间件、CAF?容器云平台三大技术构成了蚂蚁金服金融级的分布式架构。金融交易技术最关键的目标是“数据不丢失,业务不停机”。目前,TRaaS 技术风险防控平台(Technological Risk-defence as a Service)已一跃成为技术风险领域最为成熟的产品,在高可用架构(异地多活、全链路压测)、资损防控(交易实时核对、自动决策)、智能运维(AIOps故障自愈)等功能上做到了极致。而金融级分布式架构SOFAStack(Scalable Open Financial Architecture Stack)专注为金融用户提供安全、敏捷的基础架构能力,解决传统集中式架构转型的困难,将传统集中式架构转变为分布式系统架构。以人保健康为例,借助SOFAStack,其互联网保险云核心业务处理能力提升了上千倍,并支持弹性扩容,出单时间达到每秒1000单,外部渠道产品接入效率提升6倍,新产品上线时间缩短80%以上。经过四代架构演进,八年“双十一”的考验,现在SOFA已经从中间件这一层开始,逐渐对外进行开放和开源。金融安全技术安全是蚂蚁金服BASIC五大技术开放战略之一(Blockchain区块链、Artificial intelligence金融智能、Security安全、IoT物联网和Computing计算),事实上十多年以来,在业务场景的迫切需求的驱动下,蚂蚁金服的风控技术也经历了多次升级迭代,才发展成一套以AI智能算法、生物核身为基础的多层级立体闭环风控系统——蚂蚁风险大脑(Risk Brian)。人脸识别、指纹识别、虹膜识别、活体检测等技术加上智能设备终端、传感器识别等共同组成了蚂蚁风险大脑数字核身解决方案。面对日益复杂的新金融场景监管,地方金融监管机构正在承担越来越多的责任,同时监管痛点也逐步显现出来。而当下,蚂蚁风险大脑集风险感知、风险识别、智能进化、自动策略调整4大功能为一身,已形成了“金融消费者教育预警”、“7+4行业监测”、“涉众金融风险防控”、“金融风险联动处置”、“投资人信访登记”等完整的防控链路。目前,蚂蚁风险大脑已与北京、天津、广州等多个地方金融监管部门建立合作,共同保护消费者合法权益。全面、多样化的数字身份认证体系也是安全技术一大亮点。运用ZOLOZ(生物认证),对人脸识别的准确率高达99.99%, 覆盖2亿+互联网金融用户,确保20亿+次交易安全;运用IFAA(本地生物认证框架),实现覆盖终端设备12亿台,支持380款Android手机,TEE级别、高安全性,设备接入轻量快速低成本,周期从4个月降至1周内。除此之外,AlphaRisk (智能风控引擎)在风险感知、风险识别、智能进化、自动驾驶上也有着诸多应用,向着自动化、自学习、高准确率、高计算性能、自适应的方向进化。金融智能决策技术蚂蚁金服的金融智能决策技术与旗下网商银行独创的“310”模式息息相关。“310”即“3分钟申请、1秒钟到账、0人工干预”的服务标准,至今服务了1000万中小微企业的贷款。2018年6月,蚂蚁金服董事长兼CEO井贤栋透露,网商银行将启动“凡星计划”:未来三年,网商银行将与1000家各类金融机构合作,服务3000万家小微企业和个体经营户。在过去,发放一笔小微企业贷款的平均人力成本在2000元,而网商银行通过技术支撑的“310”模式,让每笔贷款的平均运营成本降低至2.3元,其中2元是计算和存储硬件等技术投入费用。可以说,技术降低了金融服务的成本,实现了商业上的可持续发展。具体运行方式上,金融智能决策技术涉4大步骤,分别是数据的采集与计算、AB试验体系和BI深度分析、统一指标与策略管理、模拟训练和预测平台等,至今已积累10万余项指标体系、3000多种风控策略,仅行业化风控模型就建立100多个。与此同时,在2017双11支付宝 25.6万笔支付每秒也需要其迅速做出大量高效的决策,最难得的是其资损率一直小于百万分之0.5的水平,交易资金的安全性得到了高度保障。新一代金融交互技术在新一代金融交互技术上,蚂蚁金服有着坚实的中台能力,新一代mPaaS平台,让客户端运行更为高效与稳定;小程序的组件和API则将支付宝特色能力与系统原生能力做了紧密地结合,实现了一次开发多端投放,并可以无缝迁移支付宝小程序到自己的App中;Ant Design让用户研究、交互模式、设计语言等形成了良好的循环圈,将终端用户的体验提升到了极致。具体来看,开发者能够利用蚂蚁金服移动开发平台mPaaS做好移动App的开发、管理、发布,并做好App全生命周期的管理,其中包括了开发期的研发测试、打包构建、发布管理,还有发布之后的用户行为分析、闪退分析等。2018年9月27日,支付宝小程序一站式云服务正式开放公测,为小程序开发者提供了完整的云端支持,让开发者无需自己搭建服务器,即可实现支付宝小程序的快速上线和迭代,大大节省开发成本、加快开发速度。如果说PaaS平台是对企业后台服务的生命周期的管理,包括研发、发布、监控这一套流程,那么mPaaS就是对移动应用App一整套全生命周期的管理服务,能有效降低技术门槛、减少研发成本、提升开发效率,协助金融机构快速搭建稳定高质量的移动应用。区块链技术蚂蚁金服自研可控的金融级区块链平台已经在多个社会和商业应用场景实现多机构、多国全球部署,提供面向政府、企业和普通百姓的各类数字服务。同时,蚂蚁区块链解决了很多区块链产业面临的技术挑战,在性能、安全性以及跨链交互等多个技术难点的研究与攻关进展方面均处于世界前列,已经具备金融级平台所需要的高性能、高可靠和高安全的技术特点。蚂蚁金服区块链总体定位是做一个信任连接的基础设施,与信美人寿相互保险社的合作是其区块链技术的试水,而在天猫跨境电商溯源、茅台溯源这两个可信的溯源服务上,区块链技术日臻成熟。2017年11月,蚂蚁金服正式上线关于天猫境外商品的跨境溯源的服务。在这个场景中,支付宝用户从天猫针对来自澳洲、新西兰26个商品、奶制品提供了关于每一瓶奶制品的身份证的溯源码服务。目前,蚂蚁金服在区块链领域申请了160多件专利,国家专利局公开授权的有65件,在知识产权产业媒体IPRdaily最新发布的《2018年全球区块链专利企业排行榜》排名第一。目前,蚂蚁区块链的专利方向主要集中于底层技术,并将这些技术首先应用在公益慈善、食品安全、跨境汇款、房屋租赁等更具社会价值的民生领域。2018年6月25日,蚂蚁金服宣布全球首个基于区块链技术的电子钱包跨境汇款服务在香港上线。在香港工作22年的菲律宾人Grace幸运地第一个尝鲜,整个汇款过程耗时仅3秒,而在以前需要短则10分钟、长则几天。在区块链技术的支持下,支付宝香港钱包可以为在港菲律宾劳工提供7×24小时不间断的跨境汇款服务,实现3-6秒汇款到账服务体验。同时,大大降低了多方对账成本。据了解,蚂蚁金服依次攻克了符合各国监管要求的隐私保护设计、区块链节点跨境多地多机房部署、低延时智能合约交易确认等技术难题。“BASIC”综合技术实力跻身一线可以说,除了上文介绍的数字金融五大关键技术,蚂蚁金服的综合技术实力在经历了“原始积累”之后,已经跻身一线技术厂商。“BASIC”是现在的蚂蚁金服最常提到的核心技术能力,即Blockchain(区块链)、AI(金融智能)、Security(安全)、IoT(物联网)、Computing(计算),未来所有的金融科技都围绕着这些技术来展开并实施开放开源。此外,蚂蚁金服完全自主研发的OceanBase 是高性能、高可扩展、数据强一致的金融级分布式关系型数据库,具备丰富的关系数据库功能,支持完整的 ACID 特性,首创的“三地五中心”城市级故障无损容灾方案正成为越来越多金融机构核心系统高可用的选择。OceanBase还高度兼容 MySQL,让用户能够以最小的迁移成本使用高性能、可扩展、持续可用的分布式数据库服务,同时对用户数据提供金融级可靠性的保障。而在最近几年被业界广泛关注的图数据库领域,蚂蚁金服经过3年多的探索,也自主研发出多项指标领先业界的金融级分布式图数据库GeaBase。GeaBase具备高性能、高可用、高扩展性及可移植性强等多重特性,支撑着蚂蚁金服旗下支付的风险控制、反洗钱、反欺诈、反刷单、反套现、金融案件审理、知识图谱、会员拉新、好友推荐、理财资讯推荐等众多的业务和应用。目前,GeaBase不仅广泛应用于蚂蚁金服的生态体系内,而且已经技术对外开放,正与多家银行等企业开展合作。从开放到开源,蚂蚁金服的“暖科技”在探索新的空间蚂蚁金服是最早提出技术开放的企业之一。在2015-2018三年间,从“互联网推进器计划”到“成熟一个开放一个”,蚂蚁金服公布的产品数量从5个增长到了80个,解决方案从3个发展到了50个,未来将以“蚂蚁金融科技”为技术输出品牌。现在,蚂蚁金融科技正式进入了3.0时代:支付宝对内延续“BASIC”战略,对外开放的技术越来越完整、越来越核心,是成建制、有体系的全面开放,并实现了技术商业化。业务上,实现了余额宝开放、借呗开放、花呗开放、小微企业贷款开放、蚂蚁财富平台、蚂蚁保险平台、蚂蚁森林等的开放……能力上,实现了小程序、生活号、实名核身能力、信用能力、风控能力、会员运营能力的开放……技术上,实现了区块链、金融智能、金融安全、金融分布式框架、移动开发、金融分布式数据库等100%开放……此外,在开源这条路上,蚂蚁金服一直保持着自己的节奏。2016年5月,企业级产品的设计体系Ant Design 1.0正式发布;2016年9月,企业级Node.js框架Egg宣布开源;2017年11月,专业的数据可视化解决方案AntV 3.0发布;2018年1月,首届蚂蚁金服体验科技大会在杭州蚂蚁Z空间成功举办;2018年4月,Ant Design成为国内公司star数最多的开源项目;2018年4月,蚂蚁金服启动分布式中间件开源计划,用于快速构建金融级云原生架构。……蚂蚁金服副CTO胡喜此前表示,蚂蚁金服内部建立了一个开源共建的体制,代码完全开放,其他业务的垂直BU自己也可以实现定制化需求。蚂蚁金服CTO程立曾说过,蚂蚁金服不是为了做技术本身而做技术,而希望用技术来解决社会当下和未来的问题。如果说用金字塔结构来描绘数字金融的社会价值,在塔顶的就是数字金融能在全球范围内带来更多平等的机会。同样,面向未来的技术探索与挑战,对“数据不丢失,业务不停机”保持极致追求,让整个数字世界变得安全可信,给全世界每一个人可信数字身份,在IoT的海量数据之上实时安全计算,蚂蚁金服责无旁贷。本文作者:华蒙阅读原文本文为云栖社区原创内容,未经允许不得转载。

November 13, 2018 · 1 min · jiezi

「造个轮子」——cicada(轻量级 WEB 框架)

前言俗话说 「不要重复造轮子」,关于是否有必要不再本次讨论范围。创建这个项目的主要目的还是提升自己,看看和知名类开源项目的差距以及学习优秀的开源方式。好了,现在着重来谈谈 cicada 这个项目的核心功能。我把他定义为一个快速、轻量级 WEB 框架;没有过多的依赖,核心 jar 包仅 30KB。也仅需要一行代码即可启动一个 HTTP 服务。特性现在来谈谈重要的几个特性。当前版本主要实现了基本的请求、响应、自定义参数以及拦截器功能。功能虽少,但五脏俱全。在今后的迭代过程中会逐渐完善上图功能,有好的想法也欢迎提 https://github.com/crossoverJie/cicada/issues。快速启动下面来看看如何快速启动一个 HTTP 服务。只需要创建一个 Maven 项目,并引入核心包。<dependency> <groupId>top.crossoverjie.opensource</groupId> <artifactId>cicada-core</artifactId> <version>1.0.0</version></dependency>如上图所示,再配置一个启动类即可。public class MainStart { public static void main(String[] args) throws InterruptedException { CicadaServer.start(MainStart.class,"/cicada-example") ; }}配置业务 Action当然我们还需要一个实现业务逻辑的地方。cicada 提供了一个接口,只需要实现该接口即可实现具体逻辑。创建业务 Action 实现 top.crossoverjie.cicada.server.action.WorkAction 接口。@CicadaAction(value = “demoAction”)public class DemoAction implements WorkAction { private static final Logger LOGGER = LoggerBuilder.getLogger(DemoAction.class) ; private static AtomicLong index = new AtomicLong() ; @Override public WorkRes<DemoResVO> execute(Param paramMap) throws Exception { String name = paramMap.getString(“name”); Integer id = paramMap.getInteger(“id”); LOGGER.info(“name=[{}],id=[{}]” , name,id); DemoResVO demoResVO = new DemoResVO() ; demoResVO.setIndex(index.incrementAndGet()); WorkRes<DemoResVO> res = new WorkRes(); res.setCode(StatusEnum.SUCCESS.getCode()); res.setMessage(StatusEnum.SUCCESS.getMessage()); res.setDataBody(demoResVO) ; return res; }}同时需要再自定义类中加上 @CicadaAction 注解,并需要指定一个 value,该 value 主要是为了在请求路由时能找到业务类。这样启动应用并访问 http://127.0.0.1:7317/cicada-example/demoAction?name=12345&id=10 便能执行业务逻辑同时得到服务端的返回。目前默认支持的是 json 响应,后期也会加上模板解析。服务中也会打印相关日志。灵活的参数配置这里所有的请求参数都封装在 Param 中,可以利用其中的各种 API 获取请求数据。之所以是灵活的:我们甚至可以这样请求:http://127.0.0.1:7317/cicada-example/demoAction?jsonData=“info”: { “age”: 22, “name”: “zhangsan” }这样就可以传递任意结构的数据,只要业务处理时进行解析即可。自定义拦截器拦截器是一个框架的基本功能,可以利用拦截器实现日志记录、事务提交等通用工作。为此 cicada 提供一个接口: top.crossoverjie.cicada.server.intercept.CicadaInterceptor。我们只需要实现该接口即可编写拦截功能:@Interceptor(value = “executeTimeInterceptor”)public class ExecuteTimeInterceptor implements CicadaInterceptor { private static final Logger LOGGER = LoggerBuilder.getLogger(ExecuteTimeInterceptor.class); private Long start; private Long end; @Override public void before(Param param) { start = System.currentTimeMillis(); } @Override public void after(Param param) { end = System.currentTimeMillis(); LOGGER.info(“cast [{}] times”, end - start); }}这里演示的是记录所有 action 的执行时间。目前默认只实现了 action 的拦截,后期也会加入自定义拦截器。拦截适配器虽说在拦截器中提供了 before/after 两个方法,但也不是所有的方法都需要实现。因此 cicada 提供了一个适配器:top.crossoverjie.cicada.server.intercept.AbstractCicadaInterceptorAdapter我们需要继承他便可按需实现其中的某个方法,如下所示:@Interceptor(value = “loggerInterceptor”)public class LoggerInterceptorAbstract extends AbstractCicadaInterceptorAdapter { private static final Logger LOGGER = LoggerBuilder.getLogger(LoggerInterceptorAbstract.class) ; @Override public void before(Param param) { LOGGER.info(“logger param=[{}]",param.toString()); }}性能测试既然是一个 HTTP 服务框架,那性能自然也得保证。在测试条件为:300 并发连续压测两轮;1G 内存、单核 CPU、1Mbps。用 Jmeter 压测情况如下:同样的服务器用 Tomcat 来压测看看结果。Tomcat 的线程池配置:<Executor name=“tomcatThreadPool” namePrefix=“consumer-exec-” maxThreads=“510” minSpareThreads=“10”/>我这里请求的是 Tomcat 的一个 doc 目录,虽说结果看似 cicada 的性能比 Tomcat 还强。但其实这个对比过程中的变量并没有完全控制好,Tomcat 所返回的是 HTML,而 cicada 仅仅返回了 json,当然问题也不止这些。但还是能说明 cicada 目前的性能还是不错的。总结本文没有过多讨论 cicada 实现原理,感兴趣的可以看看源码,都比较简单。在后续的更新中会仔细探讨这块内容。同时不出意外 cicada 会持续更新,未来也会加入更多实用的功能。甚至我会在适当的时机将它应用于我的生产项目,也希望更多朋友能参与进来一起把这个「轮子」做的更好。项目地址:https://github.com/crossoverJie/cicada你的点赞与转发是最大的支持。 ...

September 3, 2018 · 2 min · jiezi