用Quartz 写定时任务

用Quartz 写定时任务Quartz是OpenSymphony开源组织在Job scheduling领域的一个开源项目,是一款清新友好的任务调度框架 Quartz两大基本功能是job和SimpleTrigger(作业和触发器) 核心的是Scheduler类 有以下几个相关类: Scheduler:定时任务调度; Job:任务类需要实现的接口; JobDetail:Job的实例,被Scheduler执行的是JobDetail,而不是Job; Trigger:触发Job的执行; JobBuilder:定义和创建JobDetail实例的接口; TriggerBuilder:定义和创建Trigger实例的接口;
用Quartz 写定时任务2019-06-18鱼鱼

对多线程的执行效率探究——合理的任务并发拆分

对多线程的执行效率探究——合理的任务并发拆分通常,我们选择多线程执行任务有两个理由,一是复杂任务采用多线程处理能够在发生并发时让用户减少等待也能防止阻塞,一是充分利用空闲时间,提高任务处理的效率,就后者而言,此处探讨不考虑客户端并发是否有必要把一个任务拆分成多线程来处理 为了探究多线程的效率问题,我做了一个实验,将不同种类的任务分别用单线程和多线程执行,同时也试验了不同种类的锁机制 测试基于Java 8的版本,希望看到总结可以直接点击到文末 开启五个线程执行任务,设定了足够次数的循环输出,输出的数字和当前线程,利用System.currentTimeMillis()统计任务用时 (代码略)以下是相同任务在不同环境下执行多次的平均执行时间
对多线程的执行效率探究——合理的任务并发拆分2019-12-09鱼鱼

AI大模型定价对比

AI大模型定价对比https://open.bigmodel.cn/pricing 火山方舟也提供端点(GLM3 0.001) https://openai.com/ja-JP/api/pricing/ 出入价格不一样 官网和火山都有 另外有免费版本的
AI大模型定价对比2024-12-18鱼鱼

使用RPC与Restful接口调用服务

使用RPC与Restful接口调用服务在SOA和微服务架构中,远程通信是无法避免的,最常用的远程通信有两种方式: restful的接口,使用Http通信 使用dubbo或是Spring Cloud组件进行 RPC协议远程调用,可选地使用socket通信 不同的人对 RPC调用会有不同的看法,甚至对rpc本身的理解都不甚相同,但我认为 RPC有两种倾向: 一为语义化的 RPC 没有统一的请求规范,数据格式在开发人员中很难达成一致,在使用传统Http调用时,交互的双方需要约定一份“API文档”以保证数据格式的唯一性,这样API格式本身就成为了一道大墙,耽误研发双方的时间 但如果服务间采用语义化 RPC进行交互,双方可能并不需要一份文档,只要一份约定好的代码,并以此作为双方的依赖,在请求时也仅仅是直接调用方法本身,如此强的语义性怎能让人不爱
使用RPC与Restful接口调用服务2021-01-13鱼鱼

分布式系统中的一致性算法和问题解决

分布式系统中的一致性算法和问题解决在撰写脑裂问题相关的博客时发现脑裂问题的产生原因在不同算法下的分布式系统各不相同,需要先大致了解一致性算法并针对性的解决 市面上有很多开源的分布式系统,他们的数据一致性算法不尽相同,例如k-v系统的祖师爷——zookeeper采用的是ZAB的算法,而最近流行的Consul是raft算法,不同数据中心server沟通的方式则是gossip协议 不同的协议和方式对选举和数据同步有不同的处理机制,利用这篇文章来对比常见的分布式一致性算法 一个系统可能会使用多个不同的一致性算法,以便于在不同的业务环节上有着各自更贴切的处理 ps:有种观点是一致性算法不是很准确,因为replica也能保证数据某种程度上具有一致性,有人称之为共识算法
分布式系统中的一致性算法和问题解决2021-03-13鱼鱼

PyCharm与python快速开发

PyCharm与python快速开发Python语言作为“胶水语言”,简单易学,开发周期快,功能和扩展性强大,类库丰富 只依赖一门Java并不适用于所有情况,譬如快速开发一次性脚本(修复数据),通过使用Python效率更高,本篇文章旨在介绍本人快速入门Python的一些tips 注意,一些Python的基本语法在此不予介绍,推荐前往廖雪峰的博客查看,博客基于Python3.8版本 关于编译器等配置内容参考PyCharm帮助文档 从Python官网下载Python并安装,配置环境变量,安装PyCharm(这里 我们使用它作为IDE),这里略过 pip是python的包管理与安装工具,当你安装python后,pip也会随之被安装
PyCharm与python快速开发2021-01-16鱼鱼

浅谈代理-动态代理

浅谈代理-动态代理我们可以很轻松的实现一个简单的代理 实现静态代理是个很简单的事情,最基础的代理只需要定义一个接口(虽然不是必要,但这显然才是标准的设计)、一个被代理类和一个代理类,例如: 定义一个接口: 一个实现类: 和一个代理类: 实际使用时,我们是去调用HelloWorldProxy的方法,其将作为HelloWorld的代理实现 此种方式直接实现的代理太过于死板,因为每一种代理行为都要制定一个代理类,我们熟知的很多基于代理的实现(譬如AOP、事务)显然不可能用静态代理的方式针对每一处类切点都覆写一个代理类,这种时候就需要动态代理 我们所熟知的相当多的框架均基于动态代理开发,JDK本身基于反射(java.lang.reflect)提供了动态代理,我们只需定义代理的行为,而对于代理类的范围并不是固定值
浅谈代理-动态代理2020-10-13鱼鱼

造轮子0 浅谈设计模式

造轮子0 浅谈设计模式语义化接口的使用,譬如Aware等接口完全是语义性接口,不定义任何方法,只是用来约束一类行为 在Spring框架中有很多类似的接口 Wrapper,包装 ,相当于一个装饰器 XxxAware类表示在Spring中可感知,一般是类中需要用到Spring相关的对象时使用的 例如继承ApplicationContextAware接口后,实现setApplicationContext(ApplicationContext applicationContext)便会获得这个对象,与之对应的是XxxCapable类,继承他的类要负责实现相关的方get法负责生成Spring需要的对象
造轮子0 浅谈设计模式2019-05-26鱼鱼

第一个Vue前端独立项目构建尝试(工程化)

第一个Vue前端独立项目构建尝试(工程化)开始我的第一个前端独立项目的构建 使用webPack、npm进行项目模块化构建 安装相关软件准备构建: VSCode npm(node) 查看版本 npm -v node -v 安装相关依赖(使用淘宝镜像): npm install -g cnpm --registry=http://registry.npm.taobao.org 安装vue-cli脚手架: npm install -g vue-cli 查看版本: vue --version 进入目录后新建vue工程: vue init webpack projectname 配置相关内容:
第一个Vue前端独立项目构建尝试(工程化)2019-05-04鱼鱼

Redis原理-源码解析:数据结构3 sorted set(zset))

Redis原理-源码解析:数据结构3 sorted set(zset))Redis的set数据结构在此不多讲,同Java中原理一样,set也可以理解为是hash剥离了value的数据结构,即同为dic 但是zset(有序集合)其实在底层原理上完全不同于set 所有原理实现基于Redis版本6.0.9 先看一下基本的指令实现,着重注意中文注解的地方 t_zset.c 可以看出zset的数据结构不是固定的,在其元素数或是元素的字符串过长时,其结构为zset;否则使用ziplist数据结构(像hash一样为了节省空间),二者的创建方法如下: ziplist的代码和原理可以参考我的博客Redis原理-源码解析:数据结构2 list-鱼鱼的Java小站,就是一个节省内存的压缩的链表结构
Redis原理-源码解析:数据结构3 sorted set(zset))2021-02-28鱼鱼

盘点redis中特殊的数据类型 HyperLogLog Bitmap

盘点redis中特殊的数据类型 HyperLogLog Bitmap 基数计数(cardinality counting)通常用来统计一个集合中不重复的元素个数,例如统计某个网站的UV,或者用户搜索网站的关键词数量 数据分析、网络监控及数据库优化等领域都会涉及到基数计数的需求 要实现基数计数,最简单的做法是记录集合中所有不重复的元素集合S_uSu,当新来一个元素x_ixi,若S_uSu中不包含元素x_ixi,则将x_ixi加入S_uSu,否则不加入,计数值就是S_uSu的元素数量 这种做法存在两个问题: 当统计的数据量变大时,相应的存储内存也会线性增长 当集合S_uSu变大,判断其是否包含新加入元素x_ixi的成本变大 大数据量背景下,要实现基数计数,首先需要确定存储统计数据的方案,以及如何根据存储的数据计算基数值;另外还有一些场景下需要融合多个独立统计的基数值,例如对一个网站分别统计了三天的UV,现在需要知道这三天的UV总量是多少,怎么融合多个统计值
盘点redis中特殊的数据类型 HyperLogLog Bitmap 2022-01-12鱼鱼

Kafka服务端集群原理

Kafka服务端集群原理kafka是家喻户晓的消息队列,也因“纯粹”而闻名(高性能高吞吐、扩展较少较为简单),此篇文章整理Kafka的基本架构,将按照Kafka的版本迭代分别展示架构的演进(截至版本3.0) 我们在这里暂且只讨论Kafka服务端,对于生产者和消费者的逻辑简单带过 扫盲一下Kafka的部分概念: Producer mq生产者通用叫法 作为消息的生产者,在生产完消息后需要将消息投送到指定的目的地(某个topic的某个partition) Producer可以根据指定选择partition的算法或者是随机方式来选择发布消息到哪个partition; Consumer mq生产者通用叫法 消息消费者,向Kafka broker读取消息的客户端;,负责订阅和消费消息
Kafka服务端集群原理2022-03-10鱼鱼
网站地图
1
首页 博客 {{screen}} 第 {{page}} 页
博客索引
{{blog.createDate}} ◔ {{blog.timeline}} 小头像 {{blog.author}} {{tag}}
{{blog.likeCount}}{{blog.commentCount}}
分类下暂时没有文章哦!
主题分类
{{taggroup.label}} 

{{tag.value}}