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

函数式编程语言及工具

专栏作者
283
文章
264531
阅读量
67
订阅数
SDP(1):ScalikeJDBC-基本操作介绍
  简单来说:JDBC是一种开放标准的跨编程语言、跨数据库类型编程API。各类型数据库产品厂商都会按它的标准要求来提供针对自身产品的JDBC驱动程序。最主要的这是一套成熟的工具,在编程人员中使用很普及。既然我们的目标是开发一套标准的大数据系统集成API,那么采用JDBC系统数据接口可以沿用业内丰富的技术资源、覆盖更多类型用户的编程需要,以及降低使用门槛。对于scala编程语言来讲,ScalikeJDBC是一套最合适满足我们下面开发要求的工具库,因为它可以用最简单易用的方式来实现JDBC的基本功能。
用户1150956
2022-05-10
1.3K0
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
4850
alpakka-kafka(5)-kafka集群配置与分布式应用部署
在进入具体的kafka应用设计之前我们先把kafka集群环境配置介绍一下。多节点kafka-cluster的安装、配置非常简单,所以应该不用太多篇幅就可以完成一个完整可用的kafka-cluster环境了:
用户1150956
2021-06-21
3940
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
4180
akka-typed(9) - 业务分片、整合,谈谈lagom, 需要吗?
在讨论lagom之前,先从遇到的需求开始介绍:现代企业的it系统变得越来越多元化、复杂化了。线上、线下各种系统必须用某种方式集成在一起。从各种it系统的基本共性分析:最明显的特征应该是后台数据库的角色了,起码,大家都需要使用数据。另外,每个系统都可能具备大量实时在线用户、海量数据特性,代表着对数据处理能力有极大的要求,预示系统只有通过分布式处理方式才能有效运行。
用户1150956
2020-08-11
7600
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(4) - EventSourcedBehavior in action
前面提到过,akka-typed中较重要的改变是加入了EventSourcedBehavior。也就是说增加了一种专门负责EventSource模式的actor, 最终和其它种类的actor一道可以完美实现CQRS。新的actor,我还是把它称为persistentActor,还是一种能维护和维持运行状态的actor。即,actor内部状态可以存放在数据库里,然后通过一组功能函数来提供对状态的处理转变,即持续化处理persistence。当然作为一种具备EventSourcedBehavior的actor, 普遍应有的actor属性、方法、消息处理协议、监管什么的都还必须存在。在这篇讨论里我们就通过案例和源码来说明一下EventSourcedBehavior是如何维护内部状态及作为一种actor又应该怎么去使用它。
用户1150956
2020-06-09
4860
search(7)- elastic4s-search-filter模式
现在我们可以开始探讨ES的核心环节:搜索search了。search又分filter,query两种模式。filter模式即筛选模式:将符合筛选条件的记录作为结果找出来。query模式则分两个步骤:先筛选,然后对每条符合条件记录进行相似度计算。就是多了个评分过程。如果我们首先要实现传统数据库的查询功能的话,那么用filter模式就足够了。filter模式同样可以利用搜索引擎的分词功能产生高质量的查询结果,而且filter是可以进缓存的,执行起来效率更高。这些功能数据库管理系统是无法达到的。ES的filter模式是在bool查询框架下实现的,如下:
用户1150956
2020-05-04
3930
search(6)- elastic4s-CRUD
如果我们把ES作为某种数据库来使用的话,必须熟练掌握ES的CRUD操作。在这之前先更正一下上篇中关于检查索引是否存在的方法:elastic4s的具体调用如下:
用户1150956
2020-04-23
4590
search(0)- 企业搜索,写在前面
计划研究一下搜索search,然后写个学习过程系列博客。开动之前先说说学习搜索的目的:不是想开发个什么搜索引擎,而是想用现成的搜索引擎在传统信息系统中引进搜索的概念和方法。对我来说,传统的管理系统legacy i.t system已经走到了尽头。根本原因是信息在量上的爆发增长,传统数据管理方式已经无法兼顾了。在我看来,除了交易管理,传统的关系数据库方式在业务管理的其它方面,特别是业务相关的数据分析、决策支持等肯定是力不从心了,这些从持续多年我所经历的数据库红色锁标记就很有说服力了。无可否认,必须想办法在大数据、分布式计算方面寻找合适的解决方案。前两年已经完成了一系列分布式计算、分布式数据库,分布式流处理等博客,足够构建一个分布式大数据平台来实现对海量数据的存储、处理了。剩下最重要的问题是如何使用平台上的这些数据,即如何能轻松又高效的使用大数据,否则前面一切努力将化为乌有。现在最迫切的需求(我认为的)就是如何对这些大数据进行高效的分析、关联,组合然后产生全面、精准的业务决策或者系统使用的支持数据。也就是说可以通过搜索把大数据平台上的数据按照业务管理要求的信息内容、表现形式提供给前端系统。
用户1150956
2020-03-19
8810
restapi(7)- 谈谈函数式编程的思维模式和习惯
国庆前,参与了一个c# .net 项目,真正重新体验了一把搬砖感觉:在一个多月时间好像不加任何思考,不断敲键盘加代码。我想,这也许是行业内大部分中小型公司程序猿的真实写照:都是坐在电脑前的搬砖工人。不过也不是没有任何收获,在搬砖的过程中我似乎发现了一些现象和造成这些现象背后的原因及OOP思维、习惯模式。和大部分IT公司一样,这间公司在行业里存在了一定时间(不是初创)所以在产品和技术方面有一定的积累,通俗点就是一堆现成的c# .net 代码。然后就是项目截止日期压力。为了按时完成任务的我只能在原有代码基础上不断加功能,根本没有机会去考虑用什么样的代码模式、结构去达到更好的效果。在这个过程中有个有趣的现象引起了我的注意:基本上我只需按照某种流程(多数是业务需求)一个个增加环节就可以实现一项完整功能,当然我是不会计较这些环节对软件其它部分是否产生影响,又或者以后代码维护会不会很麻烦,只要能及时交货就行。想想这种做法恰恰是面向对象编程或所谓行令式编程的特点,即:通过逐行执行命令引导程序的状态改变,最终状态就是运行程序的结果了,或者就是功能的实现了。通过一行行增加代码最终总会到达预期的状态,不是吗。这正是OO编程的思维模式:因为程序状态体现在每行代码上,随时可以检查,验证思路,所以OOP比较容易上手(相对函数式编程而言)。
用户1150956
2019-10-08
6020
restapi(6)- do it the functional way, 重温函数式编程
再次看了看上篇博客的源代码,发现连自己都看不懂了。想是为了赶时间交货不知不觉又回到OOP行令模式了,看看下面这段代码:
用户1150956
2019-09-29
9250
restapi(5)- rest-mongo 应用实例:分布式图片管理系统之一,rest 服务
最近有同事提起想把网页上的图片存在MongoDB里,我十分赞同。比起把图片以文件形式存放在硬盘子目录的方式,MongoDB有太多的优势。首先,MongoDB是分布式数据库,图片可以跨服务器存储。在一个集群环境里通过复制集、分片等技术可以提高图片读取速度、实现数据的高可用和安全性。再就是对大量的图片可用规范的记录管理方式来进行处理,甚至在一个大流量环境里还可以用集群节点负载平衡方式来助力图片的存取。
用户1150956
2019-09-29
7560
restapi(4)- rest-mongo : MongoDB数据库前端的httpserver
完成了一套标准的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.8K0
restapi(3)- MongoDBEngine : MongoDB Scala编程工具库
最近刚好有同事在学习MongoDB,我们讨论过MongoDB应该置于服务器端然后通过web-service为客户端提供数据的上传下载服务。我们可以用上节讨论的respapi框架来实现针对MongoDB的CRUD操作。在谈到restapi之前我在这篇讨论先介绍一下MongoDB数据库操作的scala编程,因为与传统的SQL数据库操作编程有比较大的差别。
用户1150956
2019-08-06
1.3K0
restapi(2)- generic restful CRUD:通用的restful风格数据库表维护工具
研究关于restapi的初衷是想搞一套通用的平台数据表维护http工具。前面谈过身份验证和使用权限、文件的上传下载,这次来到具体的数据库表维护。我们在这篇示范里设计一套通用的对平台每一个数据表的标准维护方式。http服务端数据表维护CRUD有几个标准的部分组成:Model,Repository,Route。我们先看看这几个类型的基类:
用户1150956
2019-07-25
7000
Akka-CQRS(7)- CQRS Reader Actor 示范
我们在这篇通过一个具体CQRS-Reader-Actor的例子来示范akka-persistence的query端编程和应用。在前面的博客里我们设计了一个CQRS模式POS机程序的操作动作录入过程,并示范了如何实现CQRS的写端编程。现在我们可以根据这个例子来示范如何通过CQRS的读端reader-actor读取由writer-actor所写入的操作事件并将二进制格式的事件恢复成数据库表的行数据。
用户1150956
2019-05-25
8650
Akka-CQRS(6)- read-side
前面我们全面介绍了在akka-cluster环境下实现的CQRS写端write-side。简单来说就是把发生事件描述作为对象严格按发生时间顺序写入数据库。这些事件对象一般是按照二进制binary方式如blob存入数据库的。cassandra-plugin的表结构如下:
用户1150956
2019-05-25
5960
Akka-CQRS(0)- 基于akka-cluster的读写分离框架,构建gRPC移动应用后端架构
上一篇我们讨论了akka-cluster的分片(sharding)技术。在提供的例子中感觉到akka这样的分布式系统工具特别适合支持大量的带有内置状态的,相对独立完整的程序在集群节点上分布运算。这里重点要关注这些程序的内部状态,它们会占用系统资源包括内存。把状态保存在内存里相对存放在数据库里能显著提高程序运算效率。在系统出现各种情况下对这些非持久化的程序状态的管理自然就成为了需要考虑的问题,此其一。在一个多用户、高并发的大型分布式系统里往往数据库数据使用会产生大量的冲突影响系统性能。如果能够把数据库的写入和读取分成互不关联的操作就可以避免很多资源占用的冲突。
用户1150956
2019-05-25
5940
点击加载更多
社区活动
腾讯技术创作狂欢月
“码”上创作 21 天,分 10000 元奖品池!
Python精品学习库
代码在线跑,知识轻松学
博客搬家 | 分享价值百万资源包
自行/邀约他人一键搬运博客,速成社区影响力并领取好礼
技术创作特训营·精选知识专栏
往期视频·千货材料·成员作品 最新动态
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档