在使用定时调度任务的时候,我们最常用的,就是cron表达式了。通过cron表达式来指定任务在某个时间点或者周期性的执行。cron表达式配置起来简洁方便,无论是Spring的@Scheduled还是用Quartz框架,都支持cron表达式。但是理解cron表达式,还是需要花上几分钟的时间来学习的。
本次主要实在asynq的定时任务中又重新看到了,所以想把他掌握了,不再是去网上查查查。
cron 表达式的组成cron表达式是一个字符串,由6到7个字段组成,用空格分隔。其中前6个字段是必须的,最后一个是可选的。每个字段的含义如图所示:
从左到右,依次对每个字段指定相应的值,就可以确定一个任务的执行时间点和周期了。
值可以由数字配合字符来组合。
99%的情况下会用到的字符在大部分使用cron的场景下, - * / ? 这几个常用字符就可以满足我们的需求了。
【*】:每的意思。在不同的字段上,就代表每秒,每分,每小时等。
【-】:指定值的范围。比如[1-10],在秒字段里就是每分钟的第1到10秒,在分就是每小时的第1到10分钟,以此类推。
【,】:指定某几个值。比如[ ...
一、介绍HDFS (Hadoop Distributed File System)是 Hadoop 下的分布式文件系统,具有高容错、高吞吐量等特性,可以部署在低成本的硬件上。
二、HDFS设计原理
2.1 HDFS架构HDFS 遵循主/从架构,由单个 NameNode(NN) 和多个 DataNode(DN) 组成:
NameNode : 负责执行有关 文件系统命名空间 的操作,例如打开,关闭、重命名文件和目录等。它同时还负责集群元数据的存储,记录着文件中各个数据块的位置信息。
DataNode:负责提供来自文件系统客户端的读写请求,执行块的创建,删除等操作。
2.2 文件系统命名空间HDFS 的 文件系统命名空间 的层次结构与大多数文件系统类似 (如 Linux), 支持目录和文件的创建、移动、删除和重命名等操作,支持配置用户和访问权限,但不支持硬链接和软连接。NameNode 负责维护文件系统名称空间,记录对名称空间或其属性的任何更改。
2.3 数据复制由于 Hadoop 被设计运行在廉价的机器上,这意味着硬件是不可靠的,为了保证容错性,HDFS 提供了数据复制 ...
有栈协程与无栈协程
进程的本质就是 一个程序的执行实例。在进程模型中,进程拥有对内存、I/O 通道、I/O 设备和文件等资源的控制权。
线程则是为了解决进程的执行效率而提出的。对于多核 CPU,多线程进程可以充分利用多核的特性,成倍地提升执行效率。
在现代操作系统中,我们可以认为线程是进程的更小粒度的划分,即进程包含了一个或多个线程。下图所示为,分别是单线程的进程模型和多线程的进程模型。
用户态&内核态线程用户态线程
在线程的概念提出时,操作系统并不支持线程,为了验证线程的可行性,研究人员就编写了一个线程的函数库,用函数库来实现线程。这个线程库包含了 创建线程、终止线程 等,开发者可以通过调用这些函数来实现所需的功能,如:pthread_create、pthread_exit、pthread_join、pthread_yeild。
此时,操作系统内核对这个库一无所知,从内核的角度开,它还是按照正常的方式进行管理,即 只能一次在一个 CPU 核上运行。事实上,这也是用户态线程的缺点,这些线程只能占用一个核,无法做到并行加速,而且由于用户态线程对操作系 ...
canal简介
**canal [kə’næl]**,译意为水道/管道/沟渠,主要用途是基于 MySQL 数据库增量日志解析,提供增量数据订阅和消费
早期阿里巴巴因为杭州和美国双机房部署,存在跨机房同步的业务需求,实现方式主要是基于业务 trigger 获取增量变更。从 2010 年开始,业务逐步尝试数据库日志解析获取增量变更进行同步,由此衍生出了大量的数据库增量订阅和消费业务。
基于日志增量订阅和消费的业务包括
数据库镜像
数据库实时备份
索引构建和实时维护(拆分异构索引、倒排索引等)
业务 cache 刷新
带业务逻辑的增量数据处理
工作原理MySQL主备复制原理
MySQL master 将数据变更写入二进制日志( binary log, 其中记录叫做二进制日志事件binary log events,可以通过 show binlog events 进行查看)
MySQL slave 将 master 的 binary log events 拷贝到它的中继日志(relay log)
MySQL slave 重放 relay log 中事件,将数据变更反映 ...
统一建模语言(Unified Modeling Language,UML)是一种为
面向对象系统的产品进行说明、可视化和编制文档的一种标准语言,是非专利的第三代建模和规约语言。UML是面向对象设计的建模工具,独立于任何具体程序设计语言。
UML —> 类图 (Class Diagram)
类图是描述系统中的类,以及各个类之间的关系的静态视图。能够让开发人员在正确编写代码以前对系统有一个全面的认识。类图是一种模型类型,确切地说,是一种静态模型类型。类图表示类、接口和它们之间的协作关系。
类的表示法类图标由三个部分组成:第一个部分是类名,第二个部分是属性,第三个部分是操作。
类名在它的命名空间中唯一。类名以大写字母开头,省略多个单词之间的空格。
属性和操作在类的范围内必须无二义。属性和操作是以小写字母开头,后续单词的首字母大写,且同样省略空格。
抽象类和抽象操作用斜体表示。
属性规格说明格式:
可见性 属性名称:类型 [多重性] = 默认值 {特性字符串}
操作规格说明格式:
可见性 操作名称(参数名称:类型):返回值 {特性字符串}
可见性
公有可 ...
了解什么是JWT
JWT什么是JWT?JWT (JSON Web Token) 是目前最流行的跨域认证解决方案,是一种基于 Token 的认证授权机制。 从 JWT 的全称可以看出,JWT 本身也是 Token,一种规范化之后的 JSON 结构的 Token。
JWT 自身包含了身份验证所需要的所有信息,因此,我们的服务器不需要存储 Session 信息。这显然增加了系统的可用性和伸缩性,大大减轻了服务端的压力。
可以看出,JWT 更符合设计 RESTful API 时的「Stateless(无状态)」原则 。
并且, 使用 JWT 认证可以有效避免 CSRF 攻击,因为 JWT 一般是存在在 localStorage 中,使用 JWT 进行身份验证的过程中是不会涉及到 Cookie 的。
下面是 RFC 7519 对 JWT 做的较为正式的定义。
JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The ...
在理论计算机科学中,CAP定理(CAP theorem),又被称作布鲁尔定理(Brewer’s theorem),它指出对于一个分布式计算系统来说,不可能同时满足以下三点:[1][2]
一致性(Consistency) (等同于所有节点访问同一份最新的数据副本)
可用性(Availability)(每次请求都能获取到非错的响应———但是不保证获取的数据为最新数据)
分区容错性(Partition tolerance)(以实际效果而言,分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性,就意味着发生了分区的情况,必须就当前操作在C和A之间做出选择[3]。)
根据定理,分布式系统只能满足三项中的两项而不可能满足全部三项[4]。理解CAP理论的最简单方式是想象两个节点分处分区两侧。允许至少一个节点更新状态会导致数据不一致,即丧失了C性质。如果为了保证数据一致性,将分区一侧的节点设置为不可用,那么又丧失了A性质。除非两个节点可以互相通信,才能既保证C又保证A,这又会导致丧失P性质。
CAP理论理解
CAP 理论的 C!= 事务ACID特性中的C
我们可以把CA ...
Axios学习
Axios项目中对于axios的简单二次封装
使用yarn添加axios
yarn add axios
封装,创建一个request.js文件
import axios from "axios";const instance = axios.create({ baseURL: 'http://localhost:8080', timeout: 2000});// todo: 拦截器暂时不需要/** * 基于axios 二次封装的get 请求 * @param url * @param params * @returns {Promise<unknown>} */const get = function (url, params) { return new Promise((resolve, reject) => { instance .get(url, params) ...
这里是摘要
自我介绍环节
你不需要一开始很厉害,你需要开始才能很厉害!
一名懒惰的死宅
是名大学生
loving life & loving coding
在为找工作努力学习ing
主要技术栈:
golang
react
vue
java
邮箱:2493381254@qq.com
该思想源于2003年 Eric Evans编写的“Domain-Driven Design领域驱动设计”简称DDD,Evans DDD是一套综合软件系统分析和设计的面向对象建模方法。
服务器后端发展三个阶段
服务器后端发展三个阶段:
面向过程脚本:初始简单,业务复杂后,维护难度指数上升。–>基本不为主流使用
面向数据库表:初始难度中,业务复杂后,维护难度延迟后再指数上升。—>目前市面上主流
面向业务模型:DDD+SOA微服务的事件驱动的CQRS读写分离架构:应付复杂业务逻辑,以聚合模型替代数据表模型,以并发的事件驱动替代串联的消息驱动。真正实现以业务实体为核心的灵活拓展。初始难度高,业务复杂后,维护难度**线性上升(已很不错)**。
DDD的特点DDD革命性在于:领域模型准确反映了业务语言,而传统微服务数据对象除了简单setter/getter方法外,没有任何业务方法,即失血模型,那么DDD领域模型就是充血模型(业务方法定义在实体对象中)。
落地邻域模型设计以渠道中心(一个微服务)作为例子来做领域模型设计,核心就是设计2个图,一个是战略设计图(宏观) ...