技术文章

点击上方" 程序员历小冰 "，选择“置顶或者星标” 你的关注意义重大! 熟悉 MySQL 的同学一定都知道，MySQL 对于复杂条件查询的支持并不好。MySQL 最多使用一个条件涉及的索引来过滤，然后剩余的条件只能在遍历行过程中进行内存过滤，对这个过程不了解的同学可以先行阅读一下 《MySQL复杂where条件分析》 。 上述这种处理复杂条件查询的方式因为只能通过一个索引进行过滤，所以需要进行大量的 I/O 操作来读取行数据，并消耗 CPU 进行内存过滤，导致查询性能的下降。 而 ElasticSearch 因其特性，十分适合进行复杂条件查询，是业界主流的复杂条件查询场景解决方案，广泛应用于订单和日志查询等场景。 下面我们就一起来看一下，为什么 ElasticSearch 适合进行复杂条件查询。 ElasticSearch 简介 Elasticsearch 是开源的实时分布式搜索分析引擎，内部使用 Lucene 做索引与搜索。它提供"准实时搜索"能力，并且能动态集群规模，弹性扩容。 Elasticsearch 使用 Lucene 作为其全文搜索引擎，用于处理纯文本的数据，但 Lucene 只是一个库，提供建立索引、执行搜索等接口，但不包含分布式服务，这些正是 Elasticsearch 做的。 下面，我们来介绍一下 ElasticSearch 的相关概念。为了便于初学者理解

上一章我们聊了聊quick-thought通过干掉decoder加快训练, CNN—LSTM用CNN作为Encoder并行计算来提速等方法，这一章看看抛开CNN和RNN，transformer是如何只基于attention对不定长的序列信息进行提取的。虽然Attention is All you need论文本身是针对NMT翻译任务的,但transformer作为后续USE/Bert的重要组件，放在embedding里也没啥问题。以下基于WMT英翻中的任务实现了transfromer，完整的模型代码详见 DSXiangLi-Embedding-transformer 模型组件 让我们先过一遍Transformer的基础组件，以文本场景为例，encoder和decoder的输入是文本序列，每个batch都pad到相同长度然后对每个词做embedding得到batch * padding_len * emb_size的输入向量 假设batch=1，Word Embedding维度为512，Encoder的输入是'Fox hunt rabbit at night', 经过Embedding之后得到1 * 5 * 512的向量，以下的模型组件都服务于如何从这条文本里提取出更多的信息 Attention 序列信息提取的一个要点在于如何让每个词都考虑到它所在的上下文语境 RNN

Elasticsearch 7.x 选举算法改为基于 Raft 的实现，与标准 Raft 相比，最大的区别是允许选民可以投多票，当产生多个主节点的时候，让最后一个当选，这样，可以更快地选出主节点。但是这种机制同样也有缺点，就是会使竞选过程比较激烈。特别是当集群节点数量比较多的时候，候选人反复竞争可能会持续很长时间。 当遇到这种情况时，节点会有如下的日志： master not discovered or elected yet, an election requires at least xx nodes with ids from [] which is a quorum; discovery will continue using [] from hosts providers and [] from last -known cluster state; node term 14 , last -accepted version 71 in term 5 以及： failed to join {...} CoordinationStateRejectedException : incoming term 4996 does not match current term 但是这些报错和问题根因没有啥关系，探测到的节点已经能够达到 quorum，然后继续discovery

点击上方 蓝字 关注我们 文末有惊喜 kafka架构图 在这里插入图片描述 kafka核心控制器 定义 在kafka集群中，会选举出一个broker作为控制器(controller)，负责管理集群中所有的分区和副本的状态； 职责 监听broker变化，通过监听Zookeeper中的/brokers/ids/ 节点方式来实现 监听topic变化，通过监听Zookeeper中的/brokers/topics节点方式来实现，实时监听topic变化 管理topic、partition、broker相关的信息 更新数据的元数据信息，同步到其他的broker节点 选举过程 broker控制器选举的原理是借助于zookeeper的临时节点实现：kafka集群启动时，每个broker都会尝试争当控制器，都会往zookeeper的controller节点注册自己，但是由于zookeerper的特性，如果节点已经创建过，再创建就会失败，所以只会有一个broker创建成功，那么创建成功的broker就会成为控制器;此外其他broker都会监听这个controller节点 在这里插入图片描述 由于controller是临时节点，当控制器broker挂机之后，就会断开与zookeeper的会话连接，临时节点也会消失，其它节点监听到controller节点消失后，就会重新争取controller节点。

解决键盘一按就跳出窗口问题 参考文章： （1）解决键盘一按就跳出窗口问题 （2）https://www.cnblogs.com/zhoushuang0426/p/10081204.html 备忘一下。 来源： oschina 链接： https://my.oschina.net/u/4428122/blog/4956905

#A主机 192.168.100.120# 在主机A中创建一个子网,范围是10.52.100.2->10.52.100.254 docker network create --subnet=10.52.100.0/24 snake120 运行一个centos7的容器作为客户端 docker run --name centos -dit --network snake120 --ip 10.52.100.2 uhub.service.ucloud.cn/pub021/centos:7.4.1708 增加路由指向目标地址所在的宿主机,-net 目标IP , gw 网关IP ,默认eth0网卡 route add -net 10.52.121.0 netmask 255.255.255.0 gw 192.168.100.121 服务端开放转发规则，用于B主机向A主机通信 iptables -A FORWARD -j ACCEPT #B主机 192.168.100.121# 在主机B中创建一个子网,范围是10.52.121.2->10.52.121.254 docker network create --subnet=10.52.121.0/24 snake121 运行一个目标服务 docker run --name nginx -dit --network snake121 --ip

我们已经通过 Modern Android Development (简称 MAD Skills) 系列文章和在 Android 开发者文档上的 MAD Skills 内容集锦页面 与您分享了许多相关信息。现在，是时候了解一下 您的 MAD 分数 了！今天，我们将推出 MAD 计分卡，从您使用的 Jetpack 库的数量，到使用 Kotlin 编写的应用所占的百分比，通过这些指标展示您作为 Android 开发者的 "时髦" (modern) 程度。 您的 MAD 计分卡将通过 Android Studio 为您带来实用信息，例如通过 Android App Bundle 打包方式，能将您的应用大小缩减多少。它会对各种关键的 MAD 技术进行重点介绍，包括您可以使用的特定 Jetpack 库和 Kotlin 功能。您甚至会因为自己掌握的 MADdest 技能而获得专属的 MAD 角色 (说不定，您也许会成为 MAD 科学家)。 MAD 计分卡获取方法 新版 Android Studio 插件支持个性化展示您的 MAD 分数，以下是获取和分享计分卡的方法: 第 1 步，安装插件: 在 Android Studio 的插件市场中搜索并下载 MAD Scorecard 插件。通过 Studio 轻松快速地完成安装。 第 2 步，运行插件: 您可以随时在 Studio 主菜单的

纯解释执行（启动很快，执行很慢） -Xint 纯编译执行（启动很慢，执行很快） -Xcomp 混合执行（默认） -Xmixed 设置热点代码（JVM使用编译执行的条件） -XX:CompileThreshold=10000 测试 public class MyTest { public static void main(String[] args) { long t1 = System.currentTimeMillis(); for (int i = 0; i < 100000; i++) { myLoop(); } long t2 = System.currentTimeMillis(); System.out.println(t2 - t1); } public static void myLoop(){ for (int i = 0; i < 1000000; i++) { int j = i / 2; } } } 三种模式分别测试的结果： 纯解释： 实在太久，直接放弃...... 纯编译： 有一定的编译时间， 执行时间为 2 混合： 编译很快， 执行时间为 5 来源： oschina 链接： https://my.oschina.net/icefoxhz/blog/4956878

企业转型 一个集热度与难度于一身的话题宠儿 刚刚结束的两会中也多次提及它 但......转型转了这么多年 一顿操作猛如虎 战绩始终0杠5 于是，大家纷纷加入吐槽 企业转型难！ 企业数字化转型难！！ 转型为分析驱动型企业更是难上加难！！！ 转型这么难，还有企业能“上岸”嘛? BUT，安顾做到了！ （图片来自于安顾保险集团官网） 那么，安顾是谁？它是怎样成功转型的？应该分几步推进转型？ 且听小赛慢慢为大家介绍~ 首先，我们先来认识一下这家企业： 安顾保险集团 安顾保险集团 (ERGO Group AG) 是德国和其他国际市场主要保险商之一，拥有40,000多名员工，销售合作伙伴遍布全球，保费总收入达187亿欧元。公司提供各种保险和金融产品，在德国国内市场的客户超过900万（要知道，德国总人口数也不过8000多万人，相当于每9个人中就有1个是安顾的客户）。 那么，为什么安顾要转为分析驱动型企业，难道能让它C位出道？（吃瓜脸） 首先，转型为分析驱动型企业是安顾战略计划的重要组成部分。其次，好处是 可以系统化利用高级分析提取数据中的价值，同时优化整个价值链流程 ，包括：产品设计定价、销售分销、承销、风险管理、客户交互、索赔、服务和运营。 既然分析驱动型企业好处这么多，那么到底怎样才能成功转型呢？听说安顾只用了4步，跟随小赛一起看看吧！ 第一步 培育高级分析技能 为实现“分析驱动型企业

请求处理流程 (1) DispatcherServlet是Spring MVC中的前端控制器，负责接收Request并且将Request转发给对应的处理组建 (2) HandMapping是Spring MVC中完成URL到Controller映射的组建。DispatcherServlet接收Request，然后从HandMapping中查找处理Request的Controller (3) Controller处理Request，并返回ModelAndView对象，Controller是Spring MVC中负责处理Request的组建，ModelAndView是封装结果视图的组建 (4)(5)(6) 是试图解析器解析ModelAndView对象并返回对应的视图给客户端的过程 综述 容器初始化的时候会建立URL和Controller中方法的对应关系，保存到Handler Mapping中，用户请求是根据请求的URL快速定位到Controller中的某个方法。Web容器启动时会通知Spring初始化容器(加载Bean的定义信息和初始化所有的单例Bean)，然后Spring MVC会遍历容器中的Bean，获取每个Controller中所有方法的URL，将URL和Controller保存一个Map中。 来源： oschina 链接： https://my.oschina.net/u