首页
学习
活动
专区
工具
TVP
发布

函数式编程语言及工具

专栏作者
283
文章
263982
阅读量
67
订阅数
alpakka-kafka(10)-用kafka实现分布式近实时交易
  随着网上购物消费模式热度的不断提高,网上销售平台上各种促销手段也层出不穷,其中“秒购”已经是各种网站普遍流行的促销方式了。“秒购”对数据的实效性和精确性要求非常高,所以通过分布式运算实现高并发数据处理应该是正确的选择。不过,高并发也意味着高频率的数据操作冲突,而高频使用“锁”又会严重影响效率及容易造成不可控异常,所以又被迫选择单线程运行模式。单线程、分布式虽然表面相悖,不过如上篇博文所述:可以利用akka-cluster-sharding分片可指定调用的特性将一种商品的所有操作放到同一个shard上运算(因为shard即是actor,mailbox里的运算指令是按序执行的)可容许在一个分布式环境下有多个分片来同时操作。如此可在获取分布式运算高效率的同时又保证了数据的安全性和完整性。
用户1150956
2022-05-10
3040
alpakka-kafka(9)-kafka在分布式运算中的应用
  kafka具备的分布式、高吞吐、高可用特性,以及所提供的各种消息消费模式可以保证在一个多节点集群环境里消息被消费的安全性:即防止每条消息遗漏处理或重复消费。特别是exactly-once消费策略:可以保证每条消息肯定只被消费一次。换句话说就是在分布式运算环境里kafka的消息消费是能保证唯一性的。
用户1150956
2022-05-10
3000
SDP(1):ScalikeJDBC-基本操作介绍
  简单来说:JDBC是一种开放标准的跨编程语言、跨数据库类型编程API。各类型数据库产品厂商都会按它的标准要求来提供针对自身产品的JDBC驱动程序。最主要的这是一套成熟的工具,在编程人员中使用很普及。既然我们的目标是开发一套标准的大数据系统集成API,那么采用JDBC系统数据接口可以沿用业内丰富的技术资源、覆盖更多类型用户的编程需要,以及降低使用门槛。对于scala编程语言来讲,ScalikeJDBC是一套最合适满足我们下面开发要求的工具库,因为它可以用最简单易用的方式来实现JDBC的基本功能。
用户1150956
2022-05-10
1.3K0
SDP(0):Streaming-Data-Processor - Data Processing with Akka-Stream
   再有两天就进入2018了,想想还是要准备一下明年的工作方向。回想当初开始学习函数式编程时的主要目的是想设计一套标准API給那些习惯了OOP方式开发商业应用软件的程序员们,使他们能用一种接近传统数据库软件编程的方式来实现多线程,并行运算,分布式的数据处理应用程序,前提是这种编程方式不需要对函数式编程语言、多线程软件编程以及集群环境下的分布式软件编程方式有很高的经验要求。前面试着发布了一个基于scalaz-stream-fs2的数据处理工具开源项目。该项目基本实现了多线程的数据库数据并行处理,能充分利用域内服务器的多核CPU环境以streaming,non-blocking方式提高数据处理效率。最近刚完成了对整个akka套装(suite)的了解,感觉akka是一套理想的分布式编程工具:一是actor模式提供了多种多线程编程方式,再就是akka-cluster能轻松地实现集群式的分布式编程,而集群环境变化只需要调整配置文件,无需改变代码。akka-stream是一套功能更加完整和强大的streaming工具库,那么如果以akka-stream为基础,设计一套能在集群环境里进行分布式多线程并行数据处理的开源编程工具应该可以是2018的首要任务。同样,用户还是能够按照他们熟悉的数据库应用编程方式轻松实现分布式多线程并行数据处理程序的开发。
用户1150956
2022-05-10
4060
alpakka-kafka(7)-kafka应用案例,消费模式
上篇描述的kafka案例是个库存管理平台。是一个公共服务平台,为其它软件模块或第三方软件提供库存状态管理服务。当然,平台管理的目标必须是共享的,即库存是作为公共资源开放的。这个库存管理平台是一个Kafka消费端独立运行的软件。kafka的生产方即平台的服务对象通过kafka生产端producer从四面八方同时、集中将消息写入kafka。库存管理平台在kafka消费端不间断监控kafka里新的未读过的消息并及时读取,解析消息获取发布者对库存管理的指令,然后按指令更新库存状态。
用户1150956
2021-08-19
4020
alpakka-kafka(8)-kafka数据消费模式实现
上篇介绍了kafka at-least-once消费模式。kafka消费模式以commit-offset的时间节点代表不同的消费模式,分别是:at-least-once, at-most-once, exactly-once。上篇介绍的at-least-once消费模式是通过kafka自身的auto-commit实现的。事后想了想,这个应该算是at-most-once模式,因为消费过程不会影响auto-commit,kafka在每个设定的间隔都会自动进行offset-commit。如果这个间隔够短,比整个消费过程短,那么在完成消费过程前就已经保存了offset,所以是at-most-once模式。不过,如果确定这个间隔一定大于消费过程,那么又变成了at-least-once模式。具体能实现什么消费模式并不能明确,因为auto-commit是无法从外部进行控制的。看来实现正真意义上的at-least-once消费模式还必须取得offset-commit的控制权才行。
用户1150956
2021-08-19
4840
alpakka-kafka(6)-kafka应用案例,用户接口
了解了kafka原理之后,对kafka的的应用场景有了一些想法。在下面的一系列讨论中把最近一个项目中关于kafka的应用介绍一下。
用户1150956
2021-08-12
4720
alpakka-kafka(5)-kafka集群配置与分布式应用部署
在进入具体的kafka应用设计之前我们先把kafka集群环境配置介绍一下。多节点kafka-cluster的安装、配置非常简单,所以应该不用太多篇幅就可以完成一个完整可用的kafka-cluster环境了:
用户1150956
2021-06-21
3920
alpakka-kafka(4)-kafka应用案例-系统分析
上一篇我们通过示范案例基本了解了一个独立交易类型的库存管理模块应该是怎样的一块业务。这篇我们讨论一些如何从技术上来实现这样的业务模块。讲确切点应该说如何借助kafka的特性来实现功能开发。
用户1150956
2021-04-01
4690
alpakka-kafka(3)-kafka应用案例-需求分析
在大型复杂的应用中,业务模块之间总是相互关联,相互纠缠。无论对业务管理或软件开发方面都会造成困惑:从业务管理方面难以厘清确切的管理范围和职责:就是说不知一项业务具体谁来管。在软件开发方面则无法确定开发人员的具体分工和维护责任,即确定一项业务功能具体靠谁来修改、优化。拿一个普通的网上购物过程来说,除商品拣选过程外的优惠价选定、库存扣减、支付又会涉及商品定价管理、库存管理、财务管理等独立的业务模块。如果纯从软件开发角度来描述:负责开发购物流程的开发人员还需要兼顾优惠价计算、库存扣减、支付等业务操作。因为商品定价、库存管理、财务管理等都有可能是其它人负责开发的业务模块。一件商品拣选有可能造成该商品的定价调整、库存变动可能驱动采购、配货等业务的发生、支付也会是一些财务操作的启动原因。购物流程开发人员应该是不容许直接去实现这些业务操作的。为了解决这些矛盾,必须先实现业务模块的松散耦合。听起来有点像CQRS,不过是更广义的domainRS业务模块分离。在接触kafka之前,我们一般用soa模式由负责一块业务功能开发的程序员提供一套完整的对外业务操作api,就可以实现程序员各自独立工作,各管自己的一亩二分地。不过,完成的系统经常会出现内部处理业务速度跟不上外部api调用频率的情况,轻者拖滞api调用线程,重则造成业务处理异常。这个时候kafka应该能在解决方案里发挥特殊作用:如果我们把kafka引入到业务模块集成,业务模块之间通过消息/事件队列event-queue进行沟通就可以实现更高程度的、更高效率的、交易事务类型的业务集成了。
用户1150956
2021-03-30
3160
alpakka-kafka(2)-consumer
alpakka-kafka-consumer的功能描述很简单:向kafka订阅某些topic然后把读到的消息传给akka-streams做业务处理。在kafka-consumer的实现细节上,为了达到高可用、高吞吐的目的,topic又可用划分出多个分区partition。分区是分布在kafka集群节点broker上的。由于一个topic可能有多个partition,对应topic就会有多个consumer,形成一个consumer组,共用统一的groupid。一个partition只能对应一个consumer、而一个consumer负责从多个partition甚至多个topic读取消息。kafka会根据实际情况将某个partition分配给某个consumer,即partition-assignment。所以一般来说我们会把topic订阅与consumer-group挂钩。这个可以在典型的ConsumerSettings证实:
用户1150956
2021-03-02
5730
alpakka-kafka(1)-producer
alpakka项目是一个基于akka-streams流处理编程工具的scala/java开源项目,通过提供connector连接各种数据源并在akka-streams里进行数据处理。alpakka-kafka就是alpakka项目里的kafka-connector。对于我们来说:可以用alpakka-kafka来对接kafka,使用kafka提供的功能。或者从另外一个角度讲:alpakka-kafka就是一个用akka-streams实现kafka功能的scala开发工具。
用户1150956
2021-03-02
9180
kakafka - 为CQRS而生
前段时间跟一个朋友聊起kafka,flint,spark这些是不是某种分布式运算框架。我自认为的分布式运算框架最基础条件是能够把多个集群节点当作一个完整的系统,然后程序好像是在同一台机器的内存里运行一样。当然,这种集成实现方式有赖于底层的一套消息系统。这套消息系统可以把消息随意在集群各节点之间自由传递。所以如果能够通过消息来驱动某段程序的运行,那么这段程序就有可能在集群中任何一个节点上运行了。好了,akka-cluster是通过对每个集群节点上的中介发送消息使之调动该节点上某段程序运行来实现分布式运算的。那么,kafka也可以实现消息在集群节点间的自由流通,是不是也是一个分布式运算框架呢?实际上,kafka设计强调的重点是消息的接收,或者叫消息消费机制。至于接收消息后怎么去应对,用什么方式处理,都是kafka用户自己的事了。与分布式运算框架像akka-cluster对比,kafka还缺了个在每个集群节点上的”运算调度中介“,所以kafka应该不算我所指的分布式运算框架,充其量是一种分布式的消息传递系统。实际上kafka是一种高吞吐量、高可用性、安全稳定、有良好口碑的分布式消息系统。
用户1150956
2020-11-26
5610
akka-streams - 从应用角度学习:basic stream parts
实际上很早就写了一系列关于akka-streams的博客。但那个时候纯粹是为了了解akka而去学习的,主要是从了解akka-streams的原理为出发点。因为akka-streams是akka系列工具的基础,如:akka-http, persistence-query等都是基于akka-streams的,其实没有真正把akka-streams用起来。这段时间所遇到的一些需求也是通过集合来解决的。不过,现在所处的环境还是逼迫着去真正了解akka-streams的应用场景。现状是这样的:跨入大数据时代,已经有大量的现代IT系统从传统关系数据库转到分布式数据库(非关系数据库)了。不难想象,这些应用的数据操作编程不说截然不同吧,肯定也会有巨大改变。特别是在传统SQL编程中依赖数据关系的join已经不复存在了,groupby、disctict等操作方法也不是所有的分布式数据库都能支持的。而这些操作在具体的数据呈现和数据处理中又是不可缺少的。当然,有很多需求可以通过集合来满足,但涉及到大数据处理我想最好还是通过流处理来实现,因为流处理stream-processing的其中一项特点就是能够在有限的内存空间里处理无限量的数据。所以流处理应该是分布式数据处理的理想方式了。这是这次写akka-streams的初衷:希望能通过akka-streams来实现分布式数据处理编程。
用户1150956
2020-09-08
9880
akka-grpc - 应用案例
上期说道:http/2还属于一种不算普及的技术协议,可能目前只适合用于内部系统集成,现在开始大面积介入可能为时尚早。不过有些项目需求不等人,需要使用这项技术,所以研究了一下akka-grpc,写了一篇介绍。本想到此为止,继续其它项目。想想这样做法有点不负责任,像是草草收场。毕竟用akka-grpc做了些事情,想想还是再写这篇跟大家分享使用kka-grpc的过程。
用户1150956
2020-09-01
8280
akka-grpc - 基于akka-http和akka-streams的scala gRPC开发工具
关于grpc,在前面的scalaPB讨论里已经做了详细的介绍:google gRPC是一种全新的RPC框架,在开源前一直是google内部使用的集成工具。gRPC支持通过http/2实现protobuf格式数据交换。protobuf即protocol buffer,是google发明的一套全新的序列化传输协议serialization-protocol,是二进制编码binary-encoded的,相对java-object,XML,Json等在空间上占有优势,所以数据传输效率更高。由于gRPC支持http/2协议,可以实现双向通讯duplex-communication,解决了独立request/response交互模式在软件编程中的诸多局限。这是在系统集成编程方面相对akka-http占优的一个亮点。protobuf格式数据可以很方便的转换成 json格式数据,支持对外部系统的的开放协议数据交换。这也是一些人决定选择gRPC作为大型系统微服务集成开发工具的主要原因。更重要的是:用protobuf和gRPC进行client/server交互不涉及任何http对象包括httprequest,httpresponse,很容易上手使用,而且又有在google等大公司内部的成功使用经验,用起来会更加放心。
用户1150956
2020-08-25
1.9K0
akka-typed(10) - event-sourcing, CQRS实战
在前面的的讨论里已经介绍了CQRS读写分离模式的一些原理和在akka-typed应用中的实现方式。通过一段时间akka-typed的具体使用对一些经典akka应用的迁移升级,感觉最深的是EvenSourcedBehavior和akka-cluster-sharding了。前者是经典akka中persistenceActor的替换,后者是在原有组件基础上在使用方面的升级版。两者都在使用便捷性方面提供了大幅度的提升。在我看来,cluster-sharding是分布式应用的核心,如果能够比较容易掌握,对开发正确的分布式系统有着莫大的裨益。但这篇讨论的重点将会集中在EventSourcedBehavior上,因为它是实现CQRS的关键。而CQRS又是大数据应用数据采集(输入)管理最新的一个重要模式。
用户1150956
2020-08-17
4170
akka-typed(9) - 业务分片、整合,谈谈lagom, 需要吗?
在讨论lagom之前,先从遇到的需求开始介绍:现代企业的it系统变得越来越多元化、复杂化了。线上、线下各种系统必须用某种方式集成在一起。从各种it系统的基本共性分析:最明显的特征应该是后台数据库的角色了,起码,大家都需要使用数据。另外,每个系统都可能具备大量实时在线用户、海量数据特性,代表着对数据处理能力有极大的要求,预示系统只有通过分布式处理方式才能有效运行。
用户1150956
2020-08-11
7580
akka-typed(8) - CQRS读写分离模式
前面介绍了事件源(EventSource)和集群(cluster),现在到了讨论CQRS的时候了。CQRS即读写分离模式,由独立的写方程序和读方程序组成,具体原理在以前的博客里介绍过了。akka-typed应该自然支持CQRS模式,最起码本身提供了对写方编程的支持,这点从EventSourcedBehavior 可以知道。akka-typed提供了新的EventSourcedBehavior-Actor,极大方便了对persistentActor的应用开发,但同时也给编程者造成了一些限制。如手工改变状态会更困难了、EventSourcedBehavior不支持多层式的persist,也就是说通过persist某些特定的event然后在event-handler程序里进行状态处理是不可能的了。我这里有个例子,是个购物车应用:当完成支付后需要取个快照(snapshot),下面是这个snapshot的代码:
用户1150956
2020-06-29
4110
akka-typed(7) - cluster:sharding, 集群分片
在使用akka-typed的过程中发现有很多地方都简化了不少,变得更方便了,包括:Supervision,只要用Behaviors.supervise()把Behavior包住,很容易就可以实现这个actor的SupervisorStrategy.restartWithBackoff策略了。然后集群化的group router使用起来也很方便,再就是集群分片cluster-sharding了。下面我们就通过一个例子来介绍cluster-sharding的具体使用方法。
用户1150956
2020-06-16
9550
点击加载更多
社区活动
腾讯技术创作狂欢月
“码”上创作 21 天,分 10000 元奖品池!
Python精品学习库
代码在线跑,知识轻松学
博客搬家 | 分享价值百万资源包
自行/邀约他人一键搬运博客,速成社区影响力并领取好礼
技术创作特训营·精选知识专栏
往期视频·千货材料·成员作品 最新动态
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档