多线程应用提高(I) 多线程常见问题、常用方法和关键字

多线程应用提高(I) 多线程常见问题、常用方法和关键字我们一般熟识的创建多线程方式即为继承Thread类或是实现Runnable接口,重写run()方法,还有创建线程池实现 手动定义一个线程任务(作为内部类)的方法现在已经不被提倡,所以遇到可能存在并发的复杂任务时,一般采用线程池来实现 一些设计并发常用并且容易被混淆的方法们: static sleep() : Thread类的静态方法,阻塞当前正在线程,不释放锁; wait() : 当前线程暂停,并释放锁且暂时无法重新获得锁,必须绑定当前对象内容锁(如使用Synchronized的同步块),知道其他线程调用notify()/notifyAll()才有机会获得锁继续执行; yield() : 当前线程暂停,此时时间片分配给其他线程,但是不会分配给优先级更低的线程;
多线程应用提高(I) 多线程常见问题、常用方法和关键字2019-12-07鱼鱼

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

Consul高级应用:多数据中心,模板与Client(Zuul)

Consul高级应用:多数据中心,模板与Client(Zuul)此文整理了Consul比较实用的高级功能:多数据中心,模板与维护模式 Consul提供了多数据中心联动的特性,目前看来多数据中心只是在查询阶段提现,各个数据中心的数据持久化和数据目录(k-v对)的更新不相干扰 也就是说,多数据中心的特性目前看来不能作为可用性的保障,当然 不排除可以手动热切换数据中心 最好判断是否使用多数据中心的情形是判断服务是否属于同一系统下,是否相同serviceId能提供相同的无状态服务,以下列举一些情景: 一个系统拥有多个域名的多套部署,提供版本一致的服务(建议使用多数据中心) 一个系统由多个服务器提供的不同服务提供(视服务具体情况,不建议使用多数据中心)
Consul高级应用:多数据中心,模板与Client(Zuul)2020-01-28鱼鱼

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

数据库的瓶颈问题解决(主从分离)与多数据源切换

数据库的瓶颈问题解决(主从分离)与多数据源切换业务中,数据库的设计是极为重要的一环,在高并发的业务中,我们可以采用集群部署来缓解请求和逻辑处理的压力,但是在数据库的层面却不行,Oracle、Mysql等数据库的吞吐量很高,但是依旧有阈值,我们不能奢求单库能解决所有的问题,假设遇到了数据库的瓶颈问题,我们可以采用怎样的手段呢 想要数据库达到瓶颈(SQL执行效率明显变慢),其实是很困难的,我们在程序的设计中基本都会使用到数据库连接池控制数据连接,但当业务量提升之后,连接池若是经常达到饱和便容易产生阻塞,我们不得不开放更多的连接数,随之而来的便是数据库承载了更多的并发,解决问题的主要方式有三: 更细的划分业务逻辑,将高频业务表单独分离开来,并通过定期清理的方式减小查询的执行时间,将不同的数据库请求分发到不同服务器的不同库,可以一定程度下解决上文所述的问题,但是应以数据库的设计性为前提,绝对不能牺牲原有设计合理的数据结构将其进行拆分,得不偿失
数据库的瓶颈问题解决(主从分离)与多数据源切换2019-08-29鱼鱼

分布式系统中的CAP原则与BASE原则

分布式系统中的CAP原则与BASE原则没有十全十美的分布式系统,分布式的痛点就在于各个节点状态的统一,CAP和BASE便是描述它的状态 本文中的分布式系统不仅指一套全是无状态的应用的服务系统,单纯依靠共享资源(如多个无状态的服务共用数据库或NoSQL而不在内存或是本身的服务容器中存储任何数据)运转的服务不是纯粹的分布式系统,分布式系统中一般需要包含有状态的服务(如主从同步的Mysql、多机哨兵模式的Redis、设置会话共享的分布式Tomcat服务) 图A 分布式架构雏形 ( 试想在上图中,若是网关通过A分区对数据做出了修改,此时还没有写入数据库但是A分区的缓存做出了调整,在分区容错的情况下A不能直接与B通信,那A与B分区就会失去一致性
分布式系统中的CAP原则与BASE原则2019-09-29鱼鱼

算法:Trie(前缀树、字典树)

算法:Trie(前缀树、字典树)前缀树(Trie,又称字典树)是一种功能倾向性很强的数据结构,通过对词汇的前缀做数结构,很容易实现查询、前缀词推荐系统,例如,我们将如下多个单词放入树结构中: [apple,bat,bee,cat,cap,car],最终生成的前缀树结构为 通过深度递归,我们很容易用较小的时间复杂度判断出符合前缀的单词在不在 假设Trie的字符集范围是固定的,并且范围不大,例如是上面的纯英文字符,假设忽略大小写总共为26个,可以选择使用桶结构进行存储,即每一个Node都是一个长度为26的bucket数组 这样看来,Trie的结构并不复杂,只通过循环不断提高深度进行遍历即可 假定字符集的范围是未知的,或者范围很大(比如中文汉字),就要放弃使用bucket结构,而是通过一个Map维护,这里使用树结构TreeMap,key为相应节点的字符
算法:Trie(前缀树、字典树)2021-01-19鱼鱼

安全框架的使用:Shiro

安全框架的使用:ShiroShiro与Sping Security均是java的安全框架,主要用于处理用户身份验证和授权 常见场景为用户系统登录 Shiro易用性强,提供了认证,授权,加密,和会话管理功能 Shiro的三大核心组件 : Subject:即当前用户概念,不止代表着某用户,也可以是进程或任何可能的事物 SecurityManager:即所有Subject的管理者,可以把他看做是一个Shiro框架的全局管理组件,用于调度各种Shiro框架的服务 作用类似于SpringMVC中的DispatcherServlet,用于拦截所有请求并进行处理 Realm:Realm是用户的信息认证器和用户的权限认证器,我们需要自己来实现Realm来自定义的管理我们自己系统内部的权限规则
安全框架的使用:Shiro2019-09-29鱼鱼

mysql前缀索引

mysql前缀索引有时候需要索引很长的字符列,这会让索引变得大且慢 通常可以索引开始的部分字符,这样可以大大节约索引空间,从而提高索引效率 但这样也会降低索引的选择性 前面已经说过,使用前缀索引,定义好长度,就可以做到既节省空间,又不用额外增加太多的查询成本 2.1因为前缀索引无法完全等于判断,只是前缀匹配,所以可能需要扫描的所以数会增加 2.2在特殊的查询里面 select id,email from SUser where email='zhangssxyz@xxx.com'; 前缀索引需要回到 id 索引再查一下,因为系统并不确定前缀索引的定义是否截断了完整信息 select count(distinct left(email,4))as L4,
mysql前缀索引2020-05-15yangwcn

Elasticsearch 入门

Elasticsearch 入门(注:本篇文章基于Elasticsearch7.7.0版本,由于版本的差异性造成的内容不一致我会尽量在文中标出,但是) Elasticsearch是基于Lucene扩展的全文搜索引擎,当我们有对大数据量的处理和搜索时,全文搜索引擎是最佳的选择,同时他提供了高扩展性、高可用性、RestFul风格的API和友好的分布式部署配置,在此我们不予详述 我们日常使用的数据库索引是数据库一种编排数据(逻辑上)从而加快查询的手段,我们暂且将这种索引方式称为正排索引,他通过对待搜索字符寻址从而找到对应的数据 但是这种索引方式对于模糊匹配会出现"断档"现象(模糊符号后的片段无法走索引查找),并且对于海量数据无论在存储上还是在查找上都略显吃力,于是在Elasticsearch中引入了倒排索引来加快查询速度
Elasticsearch 入门2020-03-06鱼鱼

Kafka服务端集群原理

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

排坑指南-异步操作HttpServletRequest丢失Cookie

排坑指南-异步操作HttpServletRequest丢失Cookie遇到了一个很奇怪的bug:请求鉴权失败,因为通过Request对象获取到的Cookie中没有数据 经过debug调用request.getCookies()方法返回了null值,但是header属性的cookie却能拿到用户的有效cookie(request.getHeader("cookie")),其中缘由,且慢慢道来 我们可以在web项目中通过Request对象很方便的获取Cookie对象: 但其内部实现其实有一层缓存逻辑,从名为"cookie"的请求头中读取并处理数据转为Cookie对象并不是个省时事,在org.apache.catalina.connector.Request类中可以看到如下代码实现:
排坑指南-异步操作HttpServletRequest丢失Cookie2020-11-11鱼鱼
网站地图
1
首页 博客 {{screen}} 第 {{page}} 页
博客索引
{{blog.createDate}} ◔ {{blog.timeline}} 小头像 {{blog.author}} {{tag}}
{{blog.likeCount}}{{blog.commentCount}}
分类下暂时没有文章哦!
主题分类
{{taggroup.label}} 

{{tag.value}}