solr

从零搭建 > 刚开始的时候，也就是创业初期或网站/产品初期，业务功能比较少，访问量也不大，通过就是采用经典的MVC架构，采用单体应用的模式进行开发，然后发布到Tomcat容器中运行，这时候我们的文件，数据库，应用都在一个服务器上，没有缓存，不追求性能优化与网站架构。 服务分离 > 随着业务的发展，系统功能的增多，访问用户量的增加，显然采用单台服务器已无法满足系统的负载，这时候，我们就需要提前采取相应的措施，应对访问流量的增加。由于我们是单体架构，优化架构在短时间内是不现实的，增加机器是一个不错的选择。这时候，我们可以把应用和数据库服务分开单独部署，如果有条件也可以把文件服务器单独部署。 集群部署 > 为了提升服务处理能力，我们通常会将Tomcat容器进行集群部署，集群主要分为三大类( 高可用集群， 负载均衡集群，科学计算集群)。我们最生产中最常见的就是负载均衡集群。 负载均衡 > 集群部署之后，我们不能让用户通过两个入口访问我们的服务，而是统一访问入口，此时我们可以在Tomcat容器前加一个负载均衡代理服务器，业界比较流行的是采用Nginx，当然使用apache也未尝不可。 用户的请求发送给Nginx反向代理服务器，然后反向代理把请求转发到后端的应用服务器。 严格意义上来说，Nginx是属于web服务器，一般用于处理静态html、css、js请求，而Tomcat属于web容器

HBase一个令人惋惜的地方，就是不支持二级索引。因此，社区有了很多补充方案来填补HBase的二级索引能力的缺陷。 今天，我们就来看看有哪些二级索引方案，通过对比各个方案的优缺点，并结合我们的具体场景做出二级索引方案选型。 1.为什么需要二级索引 HBase系统单纯从解决大数据实时读写问题角度出发，重点关注于分布式存储的扩展性、容错性、读写性能等方面，为此也牺牲了很多传统关系型数据库的功能，比如事务，SQL表达与分析等。 实际上，这是NoSQL最初的含义，以解决大数据的实时存取为首要目标，提供简单的Get，Put，Scan接口，解决用户的大数据量存储的需求。因此，HBase完全是一个非常优秀的大数据实时存取引擎，解决了传统数据库的容量问题。 就目前官方的HBase系统来说，并不支持二级索引，只有rowkey作为一级索引， 如果要对库里的非rowkey字段进行数据检索和查询， 往往要通过MapReduce/Spark等分布式计算框架进行，硬件资源消耗和时间延迟都会比较高。 为了HBase的数据查询更高效、适应更多的场景， 诸如使用非rowkey字段检索也能做到秒级响应，或者支持各个字段进行模糊查询和多字段组合查询等， 因此需要在原生HBase基础上构建二级索引， 以满足现实中更复杂多样的业务需求。一般有以下三类方案： 基于HBase的Coprocessor的方案

关于疫情： 进入主题之前，开篇先闲谈几句，这次的面试来得意外，主要也是因为疫情的缘故，所以心里上是没有准备的，这次肺炎对我们的学习、工作和生活都造成了非常大的影响，很多学校延期开学，企业也延期返工，实际上在闭关的这段时间里，我们正好可以好好利用这段时间，为自己之后想要做得事情充分做好准备，也希望肺炎赶快过去，我们的生活恢复正常。 由于疫情缘故，与阿里的HR沟通过后，采取的是视频面的方式，总共4轮均是通过视频的方式。视频面相比于现场面给人的感觉还是要稍微轻松一些的，过程没有那么紧张，交流方式也比较自然，没有太大的压迫感，只要技术ok，基本上是没什么问题，以致于这次面试顺利通过。 一面 自我介绍 项目介绍（项目中最大的技术挑战和技术难点） JVM 内存分哪几个区，每个区的作用是什么?JVM有哪些回收算法，对应的收集器有哪些？ GC 的两种判定方法 ？CMS 收集器与 G1 收集器的特点。 Java容器有哪些？哪些是同步容器,哪些是并发容器？ ArrayList和LinkedList的插入和访问的时间复杂度？ HashMap检测到hash冲突后，将元素插入在链表的末尾还是开头？ 新生代分为几个区？使用什么算法进行垃圾回收？为什么使用这个算法？ 1.8还采用了红黑树，讲讲红黑树的特性，为什么大家一定要用红黑树而不是AVL、B树之类的？ 新生代分为几个区？使用什么算法进行垃圾回收

作为一个潜入IT圈五年之久、看过数万份简历的HR，在这个问题上还是有点发言权的。HR在筛选简历时主要从公司需求出发，重点不一，不过还是有很多“通用”的套路，为了在30秒内判断出这份简历是否值得跟进，我认为程序员写简历的正确姿势是这样的： 一、基本格调 即打开简历之后的第一印象。就好比我们看见一个人，会有一个整体的感觉，他是fashion的、小清新的还是老道的？有了第一印象之后再慢慢分解来看。 加分写法： 简洁明了，逻辑结构清晰。 字体，排版，顺畅，清晰整齐就好。 最好是PDF格式，兼容性强且不易乱序。 减分写法： 设计的过于浮夸或者过于简单的。（eg.有的简历五颜六色、非常酷炫，却半天找不到联系方式，抑或是只有个人基本信息和公司名称) 写了十几页，半天打不开的，或者加载了半天，打开还乱码。 二、基本信息（姓名/性别/毕业院校/电话/邮箱/居住地/期望地） 加分写法: 清晰罗列出以上信息，这样HR就不用在接下来的电话沟通或面试中再去追问这些内容，建立我们接下来电话沟通对你的熟悉度。 再额外能加上QQ或者微信就更好了（以防有时候电话打不通哦，时不时会遇到这种情况） 减分写法： 大部分的基本信息没有写 甩给我一个Github链接，极致简洁的几句描述，需要通过你的链接来找你的联系方式。（如果不是博客写的特别好，基本是要放弃你了） 三、工作经历&项目经历 加分写法：

本书结合作者近几年的工作经验，总结了一套可直接落地、基于开源、成本低、可快速搭建的中小研发团队架构实践方法。本书共5篇22章，开篇是本书的导读;架构篇是设计思想的提升，包括企业总体架构、应用架构设计、统- -应用分层等;框架篇主讲中间件和工具的使用，包括消息队列、缓存、Job、 集中式日志、应用监控和微服务等:公共应用篇是技术与业务的结合，包括单点登录和企业支付网关:进阶篇是从架构到管理，包括技改案例、技术与业务的匹配与融合等。从架构、框架、公共应用，到案例实战和技术管理，本书将大公司的工程理念压缩应用到中小研发团队，使小团队也能构建大网站。 本书不仅适用于高级程序员、架构师、CTO,也适用于IT项目经理、技术经理，以及对架构技术感兴趣的中高级软件开发从业者。需要获取的小伙伴可以直接添加小助理vx：kaixindian331或者扫文末二维码即可免费获取！ 前言 需求:没有人会读前言? ! 解决方案:把前言内容写好，并作为开篇第1章。 话不多说直接开始“展示” 第1篇开篇. 1可参考的才是有价值的(含案例和代码) 第2篇架构篇 2企业总体架构 3应用架构设计 4统一应用分层 5生产环境诊断工具 WinDbg. 第3篇框架篇 6 RabbitMQ 快速入门及应用 7 Redis 快速入门及应用 8任务调度Job. 9应用监控系统Metrics 10 集中式日志ELK 11微服务架构

写在前面 在当今互联网行业，尤其是现在分布式、微服务开发环境下，为了提高搜索效率，以及搜索的精准度，会大量使用Redis、Memcached等NoSQL数据库，也会使用大量的Solr、Elasticsearch等全文检索服务。那么，这个时候，就会有一个问题需要我们来思考和解决：那就是数据同步的问题！如何将实时变化的数据库中的数据同步到Redis/Memcached或者Solr/Elasticsearch中呢？ 互联网背景下的数据同步需求 在当今互联网行业，尤其是现在分布式、微服务开发环境下，为了提高搜索效率，以及搜索的精准度，会大量使用Redis、Memcached等NoSQL数据库，也会使用大量的Solr、Elasticsearch等全文检索服务。那么，这个时候，就会有一个问题需要我们来思考和解决：那就是数据同步的问题！如何将实时变化的数据库中的数据同步到Redis/Memcached或者Solr/Elasticsearch中呢？ 例如，我们在分布式环境下向数据库中不断的写入数据，而我们读数据可能需要从Redis、Memcached或者Elasticsearch、Solr等服务中读取。那么，数据库与各个服务中数据的实时同步问题，成为了我们亟待解决的问题。 试想，由于业务需要，我们引入了Redis、Memcached或者Elasticsearch、Solr等服务

1. 什么是架构 我想这个问题，十个人回答得有十一个答案，因为另外的那一个是大家妥协的结果。哈哈，我理解，架构就是 骨架 ，如下图所示： 人类的身体的支撑是主要由骨架来承担的，然后是其上的肌肉、神经、皮肤。架构对于软件的重要性不亚于骨架对人类身体的重要性。 2. 什么是设计模式 这个问题我问过的面试者不下于数十次，回答五花八门，在我看来，模式就是 经验 ，设计模式就是 设计经验 ，有了这些经验，我们就能在特定情况下使用特定的设计、组合设计，这样可以大大节省我们的设计时间，提高工作效率。 作为一个工作10年以上的老码农，经历的系统架构设计也算不少，接下来，我会把工作中用到的一些架构方面的设计模式分享给大家，望大家少走弯路。总体而言，共有八种，分别是： 单库单应用模式 ：最简单的，可能大家都见过 内容分发模式 ：目前用的比较多 查询分离模式 ：对于大并发的查询、业务 微服务模式 ：适用于复杂的业务模式的拆解 多级缓存模式 ：可以把缓存玩的很好 分库分表模式 ：解决单机数据库瓶颈 弹性伸缩模式 ：解决波峰波谷业务流量不均匀的方法之一 多机房模式 ：解决高可用、高性能的一种方法 一. 单库单应用模式 这是最简单的一种设计模式，我们的大部分本科毕业设计、一些小的应用，基本上都是这种模式，这种模式的一般设计见下图： 如上图所示，这种模式一般只有一个数据库，一个业务应用层，一个后台管理系统

本书结合作者近几年的工作经验，总结了一套可直接落地、基于开源、成本低、可快速搭建的中小研发团队架构实践方法。本书共5篇22章，开篇是本书的导读;架构篇是设计思想的提升，包括企业总体架构、应用架构设计、统- -应用分层等;框架篇主讲中间件和工具的使用，包括消息队列、缓存、Job、 集中式日志、应用监控和微服务等:公共应用篇是技术与业务的结合，包括单点登录和企业支付网关:进阶篇是从架构到管理，包括技改案例、技术与业务的匹配与融合等。从架构、框架、公共应用，到案例实战和技术管理，本书将大公司的工程理念压缩应用到中小研发团队，使小团队也能构建大网站。 本书不仅适用于高级程序员、架构师、CTO,也适用于IT项目经理、技术经理，以及对架构技术感兴趣的中高级软件开发从业者。需要获取的小伙伴可以直接添加小助理vx：kaixindian331或者扫文末二维码即可免费获取！ 前言 需求:没有人会读前言? ! 解决方案:把前言内容写好，并作为开篇第1章。 话不多说直接开始“展示” 第1篇开篇. 1可参考的才是有价值的(含案例和代码) 第2篇架构篇 2企业总体架构 3应用架构设计 4统一应用分层 5生产环境诊断工具 WinDbg. 第3篇框架篇 6 RabbitMQ 快速入门及应用 7 Redis 快速入门及应用 8任务调度Job. 9应用监控系统Metrics 10 集中式日志ELK 11微服务架构

写在前面 在当今互联网行业，尤其是现在分布式、微服务开发环境下，为了提高搜索效率，以及搜索的精准度，会大量使用Redis、Memcached等NoSQL数据库，也会使用大量的Solr、Elasticsearch等全文检索服务。那么，这个时候，就会有一个问题需要我们来思考和解决：那就是数据同步的问题！如何将实时变化的数据库中的数据同步到Redis/Memcached或者Solr/Elasticsearch中呢？ 互联网背景下的数据同步需求 在当今互联网行业，尤其是现在分布式、微服务开发环境下，为了提高搜索效率，以及搜索的精准度，会大量使用Redis、Memcached等NoSQL数据库，也会使用大量的Solr、Elasticsearch等全文检索服务。那么，这个时候，就会有一个问题需要我们来思考和解决：那就是数据同步的问题！如何将实时变化的数据库中的数据同步到Redis/Memcached或者Solr/Elasticsearch中呢？ 例如，我们在分布式环境下向数据库中不断的写入数据，而我们读数据可能需要从Redis、Memcached或者Elasticsearch、Solr等服务中读取。那么，数据库与各个服务中数据的实时同步问题，成为了我们亟待解决的问题。 试想，由于业务需要，我们引入了Redis、Memcached或者Elasticsearch、Solr等服务

起源 之前做的很多项目都使用solr/elasticsearch作为全文检索引擎，它们功能全面而强大，但是对于较小的项目而言，构建和维护成本显然过高，尤其是从关系数据库/文档数据库到全文检索引擎的数据同步工作非常繁琐，且容易出错。 记得很久以前就知道postgresql数据库内置全文检索，最近发现这个数据库越来越火，于是就又研究了一番，欣喜的发现居然支持ef core，于是对其进行了一些研究，并整理心得如下。 前提 本文假设读者熟悉entity framework core的基本概念和基本使用。 目的 建立dotnet core项目，使用postgres数据库和ef core，实现常见的全文检索功能，包括 建立索引字段 基本查询 查询结果排名 查询结果高亮显示 步骤1 - 新建项目并引入packages < Project Sdk ="Microsoft.NET.Sdk" > < PropertyGroup > < OutputType > Exe </ OutputType > < TargetFramework > netcoreapp3.1 </ TargetFramework > </ PropertyGroup > < ItemGroup > < PackageReference Include ="EFCore.NamingConventions" Version =