腾讯云
开发者社区
文档
建议反馈
控制台
登录/注册
首页
学习
活动
专区
工具
TVP
最新优惠活动
文章/答案/技术大牛
搜索
搜索
关闭
发布
首页
学习
活动
专区
工具
TVP
最新优惠活动
返回腾讯云官网
函数式编程语言及工具
专栏成员
举报
283
文章
274862
阅读量
67
订阅数
订阅专栏
申请加入专栏
全部文章(283)
scala(150)
数据库(52)
编程算法(39)
sql(31)
数据处理(31)
http(26)
数据结构(20)
api(18)
其他(16)
rpc(15)
json(14)
mongodb(14)
node.js(13)
分布式(13)
jdbc(11)
kafka(11)
react(7)
nosql(6)
网站(6)
大数据(6)
es(6)
go(5)
云数据库 MongoDB(5)
java(4)
javascript(4)
网络安全(4)
xml(3)
html(3)
android(3)
日志服务(3)
面向对象编程(3)
安全(3)
actor(3)
文件存储(2)
人工智能(2)
存储(2)
开源(2)
缓存(2)
date(2)
event(2)
histogram(2)
keyword(2)
map(2)
match(2)
sequence(2)
机器学习(1)
mac os(1)
c 语言(1)
c++(1)
python(1)
bash(1)
.net(1)
asp.net(1)
jquery(1)
unix(1)
windows server(1)
bash 指令(1)
TDSQL MySQL 版(1)
消息队列 CMQ 版(1)
SSL 证书(1)
图像处理(1)
企业(1)
容器(1)
压力测试(1)
spark(1)
jvm(1)
zookeeper(1)
tcp/ip(1)
socket编程(1)
数据分析(1)
windows(1)
https(1)
系统架构(1)
nest(1)
Elasticsearch Service(1)
action(1)
adt(1)
aggregation(1)
auto(1)
behavior(1)
boost(1)
case(1)
class(1)
command(1)
count(1)
debug(1)
dsl(1)
entity(1)
entitymanager(1)
extends(1)
filter(1)
free(1)
function(1)
int(1)
io(1)
key(1)
list(1)
max(1)
metrics(1)
min(1)
pool(1)
prefix(1)
process(1)
router(1)
row(1)
scalaz(1)
search(1)
sharding(1)
slick(1)
state(1)
string(1)
sum(1)
text(1)
title(1)
union(1)
worker(1)
zip(1)
数据类型(1)
统计(1)
语法(1)
搜索文章
搜索
搜索
关闭
alpakka-kafka(9)-kafka在分布式运算中的应用
kafka
分布式
scala
编程算法
kafka具备的分布式、高吞吐、高可用特性,以及所提供的各种消息消费模式可以保证在一个多节点集群环境里消息被消费的安全性:即防止每条消息遗漏处理或重复消费。特别是exactly-once消费策略:可以保证每条消息肯定只被消费一次。换句话说就是在分布式运算环境里kafka的消息消费是能保证唯一性的。
用户1150956
2022-05-10
321
0
SDP(0):Streaming-Data-Processor - Data Processing with Akka-Stream
编程算法
分布式
scala
再有两天就进入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
433
0
alpakka-kafka(2)-consumer
node.js
kafka
scala
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
594
0
alpakka-kafka(1)-producer
kafka
scala
node.js
文件存储
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
957
0
akka-streams - 从应用角度学习:basic stream parts
scala
数据结构
数据处理
实际上很早就写了一系列关于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
1K
0
akka-grpc - 应用案例
scala
rpc
图像处理
数据结构
上期说道:http/2还属于一种不算普及的技术协议,可能目前只适合用于内部系统集成,现在开始大面积介入可能为时尚早。不过有些项目需求不等人,需要使用这项技术,所以研究了一下akka-grpc,写了一篇介绍。本想到此为止,继续其它项目。想想这样做法有点不负责任,像是草草收场。毕竟用akka-grpc做了些事情,想想还是再写这篇跟大家分享使用kka-grpc的过程。
用户1150956
2020-09-01
877
0
akka-grpc - 基于akka-http和akka-streams的scala gRPC开发工具
rpc
http
数据结构
scala
关于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.9K
0
akka-typed(10) - event-sourcing, CQRS实战
数据库
sql
scala
在前面的的讨论里已经介绍了CQRS读写分离模式的一些原理和在akka-typed应用中的实现方式。通过一段时间akka-typed的具体使用对一些经典akka应用的迁移升级,感觉最深的是EvenSourcedBehavior和akka-cluster-sharding了。前者是经典akka中persistenceActor的替换,后者是在原有组件基础上在使用方面的升级版。两者都在使用便捷性方面提供了大幅度的提升。在我看来,cluster-sharding是分布式应用的核心,如果能够比较容易掌握,对开发正确的分布式系统有着莫大的裨益。但这篇讨论的重点将会集中在EventSourcedBehavior上,因为它是实现CQRS的关键。而CQRS又是大数据应用数据采集(输入)管理最新的一个重要模式。
用户1150956
2020-08-17
437
0
akka-typed(9) - 业务分片、整合,谈谈lagom, 需要吗?
scala
api
http
数据库
在讨论lagom之前,先从遇到的需求开始介绍:现代企业的it系统变得越来越多元化、复杂化了。线上、线下各种系统必须用某种方式集成在一起。从各种it系统的基本共性分析:最明显的特征应该是后台数据库的角色了,起码,大家都需要使用数据。另外,每个系统都可能具备大量实时在线用户、海量数据特性,代表着对数据处理能力有极大的要求,预示系统只有通过分布式处理方式才能有效运行。
用户1150956
2020-08-11
790
0
akka-typed(8) - CQRS读写分离模式
scala
python
nosql
数据库
前面介绍了事件源(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
428
0
kka-typed(5) - cluster:集群节点状态监视
scala
akka-cluster对每个节点的每种状态变化都会在系统消息队列里发布相关的事件。通过订阅有关节点状态变化的消息就可以获取每个节点的状态。这部分已经在之前关于akka-cluster的讨论里介绍过了。由于akka-typed里采用了新的消息交流协议,而系统消息的发布和订阅也算是消息交换,也受交流协议约束。所以想通过重写以前示范的ClusterMemberStatus来了解一下akka-typed环境下节点状态变化消息监听的一些机制。
用户1150956
2020-06-09
617
0
akka-typed(2) - typed-actor交流方式和交流协议
网站
scala
http
akka系统是一个分布式的消息驱动系统。akka应用由一群负责不同运算工作的actor组成,每个actor都是被动等待外界的某种消息来驱动自己的作业。所以,通俗点描述:akka应用就是一群actor相互之间发送消息的系统,每个actor接收到消息后开始自己负责的工作。对于akka-typed来说,typed-actor只能接收指定类型的消息,所以actor之间的消息交流需要按照消息类型来进行,即需要协议来规范消息交流机制。想想看,如果用户需要一个actor做某件事,他必须用这个actor明白的消息类型来发送消息,这就是一种交流协议。
用户1150956
2020-06-02
735
0
akka-typed(0) - typed-actor, typed messages
scala
系统架构
akka 2.6.x正式发布以来已经有好一段时间了。核心变化是typed-actor的正式启用,当然persistence,cluster等模块也有较大变化。一开始从名称估摸就是把传统any类型的消息改成强类型消息,所以想拖一段时间看看到底能对我们现有基于akka-classic的应用软件有什么深层次的影响。不过最近考虑的一些系统架构逼的我不得不立即开始akka-typed的调研,也就是说akka-classic已经无法或者很困难去实现新的系统架构,且听我道来:最近在考虑一个微服务中台。作为后台数据服务调用的唯一入口,平台应该是个分布式软件,那么采用akka-cluster目前是唯一的选择,毕竟前期搞过很多基于akka-cluster的应用软件。但是,akka-cluster-sharding只能支持一种entity actor。毕竟,由于akka-classic的消息是没有类型的,只能在收到消息后再通过类型模式匹配的方式确定应该运行的代码。所以,这个actor必须包括所有的业务逻辑处理运算。也就是说对于一个大型应用来说这就是一块巨型代码。还有,如果涉及到维护actor状态的话,比如persistenceActor,或者综合类型业务运算,那么又需要多少种类的数据结构,又怎样去维护、管理这些结构呢?对我来说这基本上是mission-impossible。实际上logom应该正符合这个中台的要求:cluster-sharding, CQRS... 抱着一种好奇的心态了解了一下lagom源码,忽然恍然大悟:这个东西是基于akka-typed的!想想看也是:如果我们可以把actor和消息类型绑在一起,那么我们就可以通过消息类型对应到某种actor。也就是说基于akka-typed,我们可以把综合性的业务划分成多个actor模块,然后我们可以指定那种actor做那些事情。当然,经过了功能细分,actor的设计也简单了许多。现在这个新的中台可以实现前台应用直接调用对应的actor处理业务了。不用多想了,这注定就是akka应用的将来,还等什么呢?
用户1150956
2020-05-29
555
0
akka-typed(1) - actor生命周期管理
scala
编程算法
akka-typed的actor从创建、启用、状态转换、停用、监视等生命周期管理方式和akka-classic还是有一定的不同之处。这篇我们就介绍一下akka-typed的actor生命周期管理。
用户1150956
2020-05-29
856
0
search(4)- elastic4s-ElasticDsl
json
es
api
http
scala
上次分析了一下elastic4s的运算框架。本来计划接着开始实质的函数调用示范,不过看过了Elastic4s的所有使用说明文档后感觉还是走的快了一点。主要原因是elasticsearch在7.0后有了很多重点调整改变,elastic4s虽然一直在源代码方面紧跟ES的变化,但使用文件却一直未能更新,所以从说明文档中学习elastic4s的使用方法是不可能的,必须从源码中摸索。花了些时间过了一次elastic4s的源码,感觉这个工具库以后还是挺有用的:一是通过编程方式产生json请求比较灵活,而且可以通过compiler来保证json语句的正确性。二是对搜索结果的处理方面:由于返回的搜索结果是一堆又长又乱的复杂json,不敢想象自己要如何正确的解析这些json, 然后才能调用到正确的结果,但elastic4s提供了一套很完善的response类,使用起来可能会很方便。实际上elastic4s的编程模式和scala语言运用还是值得学习的。既然这样,我想可能用elastic4s做一套完整的示范,包括:索引创建、索引维护、搜索、聚合统计等,对了解和掌握elastic4s可能大有帮助。在这之前,我们还是再回顾一下elastic4s的运算原理:elastic4s的功能其实很简单:通过dsl语句组合产生json请求,然后发送给ES-rest终端, 对返回的json结果进行处理,筛选出目标答案。
用户1150956
2020-04-23
610
0
restapi(9)- caching, akka-http 缓存
http
scala
网站
缓存
restapi作为前后端交互的枢纽:面对大批量的前端请求,需要确保回复的及时性。使用缓存是一项有效工具。我们可以把多数前端请求的回复response存入缓存,特别是一些需要大量计算才能获取的回复值,更可以大大提高后端的反应速度。值得庆幸的是akka-http已经提供了对缓存的支持,是基于java8 caffein的一套缓存操作工具包的。下面就介绍一下akka-http的caching。
用户1150956
2019-11-12
587
0
restapi(6)- do it the functional way, 重温函数式编程
面向对象编程
数据库
sql
scala
再次看了看上篇博客的源代码,发现连自己都看不懂了。想是为了赶时间交货不知不觉又回到OOP行令模式了,看看下面这段代码:
用户1150956
2019-09-29
943
0
restapi(5)- rest-mongo 应用实例:分布式图片管理系统之一,rest 服务
scala
mongodb
http
云数据库 MongoDB
数据库
最近有同事提起想把网页上的图片存在MongoDB里,我十分赞同。比起把图片以文件形式存放在硬盘子目录的方式,MongoDB有太多的优势。首先,MongoDB是分布式数据库,图片可以跨服务器存储。在一个集群环境里通过复制集、分片等技术可以提高图片读取速度、实现数据的高可用和安全性。再就是对大量的图片可用规范的记录管理方式来进行处理,甚至在一个大流量环境里还可以用集群节点负载平衡方式来助力图片的存取。
用户1150956
2019-09-29
788
0
restapi(4)- rest-mongo : MongoDB数据库前端的httpserver
云数据库 MongoDB
mongodb
scala
数据库
sql
完成了一套标准的rest风格数据库CRUD操作httpserver后发现有许多不足。主要是为了追求“通用”两个字,想把所有服务接口做的更“范generic”些,结果反而限制了目标数据库的特点,最终产生了一套功能弱小的玩具。比如说吧:标准rest风格getbyId需要所有的数据表都具备id这个字段,有点傻。然后get返回的结果集又没有什么灵活的控制方法如返回数量、字段、排序等。特别对MongoDB这样的在查询操作方面接近关系式数据库的分布式数据库:上篇提到过,它的query能力强大,条件组合灵活,如果不能在网络服务api中体现出来就太可惜了。所以,这篇博文会讨论一套专门针对MongoDB的rest-server。我想达到的目的是:后台数据库是MongoDB,通过httpserver提供对MongoDB的CRUD操作,客户端通过http调用CRUD服务。后台开发对每一个数据库表单使用统一的标准增添一套新的CRUD服务。希望如此能够提高开发效率,减少代码出错机会。
用户1150956
2019-08-13
1.9K
0
restapi(3)- MongoDBEngine : MongoDB Scala编程工具库
mongodb
云数据库 MongoDB
数据库
sql
scala
最近刚好有同事在学习MongoDB,我们讨论过MongoDB应该置于服务器端然后通过web-service为客户端提供数据的上传下载服务。我们可以用上节讨论的respapi框架来实现针对MongoDB的CRUD操作。在谈到restapi之前我在这篇讨论先介绍一下MongoDB数据库操作的scala编程,因为与传统的SQL数据库操作编程有比较大的差别。
用户1150956
2019-08-06
1.3K
0
点击加载更多
社区活动
【纪录片】中国数据库前世今生
穿越半个世纪,探寻中国数据库50年的发展历程
立即查看
Python精品学习库
代码在线跑,知识轻松学
立即查看
博客搬家 | 分享价值百万资源包
自行/邀约他人一键搬运博客,速成社区影响力并领取好礼
立即体验
技术创作特训营·精选知识专栏
往期视频·千货材料·成员作品 最新动态
立即查看
领券
问题归档
专栏文章
快讯文章归档
关键词归档
开发者手册归档
开发者手册 Section 归档