ES快速入门(2)——Tokenizer、Reindex

ES快速入门(2)——Tokenizer、Reindex本篇介绍es提供的几种分词分析器和常用的开源分词分析器 es默认的分词器,中规中矩的按照 Unicode Standard Annex #29分词,一般的小写符号会忽略,对于中文等字符会逐字分割,参数max_token_length表示最大的字符长度,再切分后会继续按此切分 譬如: 会分词为: 一个无视语义,按照字符尽量收集全索引的分词方式,会前后叠加的按符号位分词,参数: 会分词为: nGram的分词很全面,但如此夸张的方式用不好会导致索引doc过大,同时使查询效率偏低 分词规则很简单,无其余规则的按空格分词: 会分词为: 在standard的基础上能够有效拆分出邮箱和url地址的格式,同样有max_token_length这一参数:
ES快速入门(2)——Tokenizer、Reindex2020-09-05鱼鱼

浅谈锁机制、主流锁设计方案

浅谈锁机制、主流锁设计方案本文旨在探讨通用的锁机制实现逻辑,以Java中常见的锁实现为例 本文提到的锁,是指通过限制并发/并行访问所添加的安全措施,本质上是通过限制线程/进程同时更改数据或是读取数据与写入数据产生时序差从而造成数据问题 锁机制中,有一些常见特性: 可重入性 指同一线程/进程携带相同的标识可以反复多次加锁,每次加锁和释放锁对应的重入次数+1/-1; 读写锁/独享共享 是锁的不同运作模式,分为读写锁,读锁与写锁、写锁与写锁是互斥的,但多个线程/进程可以同时对一个逻辑添加读锁,独享共享是另一种叫法 公平性 锁分为 公平锁和非 公平锁, 公平锁指锁释放和获取的顺序严格按照索取的顺序,非 公平锁则是等待锁的对象共同进行锁释放机会的争抢
浅谈锁机制、主流锁设计方案2024-10-15鱼鱼

Spring MVC源码和设计思想序 综述

Spring MVC源码和设计思想序 综述Spring框架整体的流程:(图片引用请注明出处)
Spring MVC源码和设计思想序 综述2019-06-05鱼鱼

ES快速入门(I)——分析分词器

ES快速入门(I)——分析分词器本文旨在快速入门Elasticsearch的分词,包括分词分析器的创建和介绍对比等,请确保在阅读前已经搭建好完备的集群 文章基于es7.0+,与稍旧版本的主要区别是没有type 在讨论分词前,我们先看一下es整体创建倒排的分词过程: 我们常说的分词器指的其实是“分析器”analyzer,es将以上常用的逻辑封装起来成为analyzer,但是语义上的分词器是指上面的tokenizer 经过了三层处理后拿到了terms数组建立最终的倒排索引: character filter:一般不会用到这个filter,是在分词前对原有的文档字段内容做转换,例如去除html的标签提取出正文内容,按正则清除和替换某些内容,你可以指定及自定义0个到多个character filter,他们将共同存在,一个文本流在经过character filter处理后,依然是文本流;
ES快速入门(I)——分析分词器2020-09-01鱼鱼

Redis高级特性:事务和pipelined以及在RedisTemplate中的应用

Redis高级特性:事务和pipelined以及在RedisTemplate中的应用Redis Pipelined是由Client提供的(是防止client端 阻塞的操作)一种请求redis的方式 Redis本身具有很高的吞吐量,因此性能最大的考察便是网络状况,如果应用到redis的网络状况不好,每次请求都将会出现轻微的 阻塞和延迟,这种延迟对于批量请求是很可怕的,譬如要进行数千次数据插入,或是批量获取数据时,我们就需要用到Pipelined Pipelined可以将多个请求无 阻塞的发出并按顺序将请求结果“打包”返回,这有点类似于并发请求,可以有效地利用等待结果的 阻塞时间 注意,Pipelined并不能保证原子性,即pipelined执行的内容可能会被其他客户端或是线程的指令"插队",若想要原子性操作,需要使用事务
Redis高级特性:事务和pipelined以及在RedisTemplate中的应用2020-06-21鱼鱼

ELK实战(Ⅰ) 基于ELK整合分布式业务日志

ELK实战(Ⅰ) 基于ELK整合分布式业务日志大多情况下,我们可能都习惯了使用linux指令查看日志,很多时候一句简简单单的tail、grep能定位绝大多数问题 但是面临复杂的目录结构和分布式系统产生的“分布式日志文件”,如果还要我们一个一个去查日志,就会耗费很多没必要的时间 可以利用ELK这套组件快速搭建一个日志系统 注意此文仅针对可能很多情况下格式不确定的业务日志,对于某些组件日志我们有更好的可视化实践方式,可以参考此系列的其他文章 对于一个日志系统,我们要确认我们的诉求,在不同的场景下采用不同的收集方式: 是否是分布式系统需要合并多个节点的日志 如果需要,则需要用分布式组件收集并合并日志,这也是一个日志系统最基本的要求;
ELK实战(Ⅰ) 基于ELK整合分布式业务日志2020-03-14鱼鱼

算法:递归

算法:递归递归算法主要寻找: 终止条件:递归的尽头 单级递归的行为:在一次递归里要做的事情 返回值:每次迭代要return的东西 例如 首先,假定方法是已经实现的 终止条件为:当当前节点(传了空节点)或下一节点(传了单节点)为空,则无需反转返回当前节点 递归行为:假定之后的节点均已实现反转,则需要将已经反转的尾部的next变为当前节点,而当前节点由于是第一个节点,其next为null 此处注意在反转前需要先留存反转后的尾部; 返回值:返回反转后的头结点
算法:递归2020-06-24鱼鱼

ELK全家桶基本使用(I)文件收集Filebeat

ELK全家桶基本使用(I)文件收集FilebeatFilebeat是Elastic中的轻量文件收集系统,相比于功能更强悍的Logstash,当我们需求很单一,读取文件内容且对文件内容没有过多复杂处理时,最好使用FileBeat取代Logstash,以免造成不必要的内存开销 文档链接 Filebeat负责收集文件并发送给下游服务 核心行为包含输入、处理过滤和输出 当然也有集成好配置的模块,通过模块与Es和Kibana链接可以直接在Kibana上看到组件的可视化 同时不难看出Filebeat其实对数据库的支持不是很健壮 截止7.6版本,开源的Filebeat可支持以下几种消息输入类型: log 用得最多的输入类型; stdin 标准的输入,从process或是piepline读取(可理解为脚本运行通道直接输入),一旦配置了这种input方式,其他 input将不再生效文档地址;
ELK全家桶基本使用(I)文件收集Filebeat2020-03-16鱼鱼

算法:动态规划解法及例题

算法:动态规划解法及例题经历过很多算法题,其中最常见的解题方法便是动态规划 动态规划(dynamic programming,即DP),是一种常见的求解最优解的方案,他通过将复杂的问题拆分为单阶段的小问题求解,核心思想是递推,通过简单基础的解一步步接近最优解 对于一个算法问题,总有一个相对令人满意的解,但却不一定是我们想要的最优解,譬如在解决动态规划中最经典的背包问题时,有些人首先想到简单省心的贪心算法,取价值最高或是性价比最高的物品组合,这种方案得到的很有可能是最优解,但贪心的算法并不适用于动态规划领域,若是物品中恰好有能将背包塞得很满的组合,而采用贪心策略却浪费了很多背包空间 其实贪心策略本身更多也是一种“相对最优”的解决方案,而很少是真正的最优,这一点请务必斟酌
算法:动态规划解法及例题2020-03-11鱼鱼

使用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鱼鱼

数据库的并发、锁机制与MVCC

数据库的并发、锁机制与MVCC在日常开发中,经常遇到数据库进行高并发操作的情况,但是我们处理并发一般都只在代码范畴而并不处理具体的数据库操作,这是因为数据库对基本的数据库操作做了锁处理,让我们可以忽略这一层的并发问题 详细可以参考Mysql的官方文档 注意:这一篇博客是针对MySQL数据库,且实用默认的 引擎InnoDb,使用其他数据库可能存在略微的差异 MySQL默认的数据库引擎InnoDB中Autocommit值为0(即自动提交事务)执行SQL语句的时候,每一条SQL语句都是一条单独的事务,所以并不存在并发的问题,数据库的锁机制已经做了很好的处理 但是当我们开启事务时,若不加处理,可能会产生一系列并发带来的问题
数据库的并发、锁机制与MVCC2021-01-24鱼鱼

Spring MVC源码和设计思想1 DispatcherServlet

Spring MVC源码和设计思想1 DispatcherServlet此篇文章是个人通过阅览Spring MVC源码的学习过程记录,包含Spring MVC的关键细节源码设计和一些设计上的tips,更近似于一种意识流的记录方式,锚点设置可能也有些乱,零零散散的点我日后有时间会统一总结起来 Restful风格的Http有八种请求方式,除了最常使用的Get与Post还有Head、Put、Delete、Options、Trace、Connect 在Restful接口的设计中,请求方方式的语义性很强,我们时常用他约束接口请求的行为,请求类型的语义: OPTIONS获取服务器支持的HTTP请求方法; HEAD跟get很像,但是不返回响应体信息,用于检查对象是否存在,并获取包含在响应消息头中的信息
Spring MVC源码和设计思想1  DispatcherServlet2019-06-03鱼鱼
网站地图
1
首页 博客 {{screen}} 第 {{page}} 页
博客索引
{{blog.createDate}} ◔ {{blog.timeline}} 小头像 {{blog.author}} {{tag}}
{{blog.likeCount}}{{blog.commentCount}}
分类下暂时没有文章哦!
主题分类
{{taggroup.label}} 

{{tag.value}}