- 博客(47)
- 资源 (2)
- 收藏
- 关注
RSS订阅原创 呕心沥血之作--手把手教你面试
Hi，各位老铁们，刚刚拿到java后端大厂的offer，特来分享下面试心得，也是经过一个月的时间准备，再加上两个月的面试历程总结出来的，希望对各位老铁有所帮助，也祝愿各位老铁找到心仪工作。关于自我介绍自我介绍注意侧重点，有些需要一笔带过，有些需要着重描述，自我介绍也决定着后面面试官问你问题的大致方向，如果答得好，可以引导面试官向你熟悉的领域进行提问，总体时间把控下，自我介绍不超过两分钟。1、首先是问好（礼貌很重要），简单自报姓名，学历以及工作经历，例：面试官您好，我叫xxx，xx年本科毕业，xx年开
2021-11-12 11:46:03
1755
原创 高并发系统设计三十一（流量控制）
上一节里，我们了解了微服务架构中常见的两种有损的服务保护策略：熔断和降级。它们都是通过暂时关闭某些非核心服务或者组件从而保护核心系统的可用性。但是，并不是所有的场景下都可以使用熔断降级的策略，比如，电商系统在双十一、618 大促的场景。这种场景下，系统的峰值流量会超过了预估的峰值，对于核心服务也产生了比较大的影响，而你总不能把核心服务整体降级吧？那么在这个时候要如何保证服务的稳定性呢？你认为可以使用限流的方案。而提到限流，我相信你多多少少在以下几个地方出错过：限流算法选择不当，导致限流效果不好；开启了
2021-11-08 16:24:30
422
原创 高并发系统设计三十（熔断降级）
到目前为止，你的电商系统已经搭建了完善的服务端和客户端监控系统，并且完成了全链路压测。现在呢，你们已经发现和解决了垂直电商系统中很多的性能问题和隐患。但是千算万算，还是出现了纰漏。本来，你们对于应对“双十一”的考验信心满满，但因为欠缺了一些面对巨大流量的经验，在促销过程中出现了几次短暂的服务不可用，这给部分用户造成了不好的使用体验。事后，你们进行了细致的复盘，追查出现故障的根本原因，你发现，原因主要可以归结为两大类。第一类原因是由于依赖的资源或者服务不可用，最终导致整体服务宕机。举例来说，在你的电商系统
2021-11-08 14:38:29
388
原创 高并发系统设计二十九（压力测试）
经过两节的学习，我们已经搭建了服务端和客户端的监控，通过监控的报表和一些报警规则的设置，你可以实时地跟踪和解决垂直电商系统中出现的问题了。不过，你不能掉以轻心，因为监控只能发现目前系统中已经存在的问题，对于未来可能发生的性能问题是无能为力的。一旦你的系统流量有大的增长，比如类似“双十一”的流量，那么你在面临性能问题时就可能会手足无措。为了解决后顾之忧，你需要了解在流量增长若干倍的时候，系统的哪些组件或者服务会成为整体系统的瓶颈点，这时你就需要做一次全链路的压力测试。那么，什么是压力测试呢？要如何来做全链
2021-11-08 10:19:54
1279
原创 高并发系统设计二十八（应用性能管理）
上一节课中，我带你了解了服务端监控搭建的过程。有了监控报表之后，你的团队在维护垂直电商系统时，就可以更早地发现问题，也有直观的工具辅助你们分析排查问题了。不过，你很快发现，有一些问题，服务端的监控报表无法排查，甚至无法感知。比如，有用户反馈创建订单失败，但是从服务端的报表来看，并没有什么明显的性能波动，从存储在Elasticsearch 里的原始日志中，甚至没有找到这次创建订单的请求。这有可能是客户端有Bug，或者网络抖动导致创建订单的请求并没有发送到服务端。再比如，有些用户会反馈，使用长城宽带打开商品
2021-11-05 15:45:04
177
原创 高并发系统设计二十七（服务监控）
在一个项目的生命周期里，运行维护占据着很大的比重，在重要性上，它几乎与项目研发并驾齐驱。而在系统运维过程中，能够及时地发现问题并解决问题，是每一个团队的本职工作。所以，你的垂直电商系统在搭建之初，运维团队肯定完成了对于机器 CPU、内存、磁盘、网络等基础监控，期望能在出现问题时，及时地发现并且处理。你本以为万事大吉，却没想到系统在运行过程中，频频得到用户的投诉，原因是：使用的数据库主从延迟变长，导致业务功能上出现了问题；接口的响应时间变长，用户反馈商品页面出现空白页；系统中出现大量错误，影响了用户的正
2021-11-05 11:27:14
228
原创 高并发系统设计二十六（配置中心）
相信在实际工作中，提及性能优化你会想到代码优化，但是实际上有些性能优化可能只需要调整一些配置参数就可以搞定了，为什么这么说呢？我给你举几个例子：你可以调整配置的超时时间，让请求快速失败，防止系统的雪崩，提升系统的可用性；你还可以调整 HTTP 客户端连接池的大小，来提升调用第三方 HTTP 服务的并行处理能力，从而提升系统的性能。你可以认为，配置是管理你系统的工具，在你的垂直电商系统中，一定会有非常多的配置项，比如数据库的地址、请求 HTTP 服务的域名、本地内存最大缓存数量等等。那么，你要如何对
2021-11-02 14:48:58
318
原创 高并发系统设计二十五（API网关）
到目前为止，你的垂直电商系统在经过微服务化拆分之后，已经运行了一段时间了，系统的扩展性得到了很大的提升，也能够比较平稳地度过高峰期的流量了。不过最近你发现，随着自己的电商网站知名度越来越高，系统迎来了一些“不速之客”，在凌晨的时候，系统中的搜索商品和用户接口的调用量，会有激剧的上升，持续一段时间之后又回归正常。这些搜索请求有一个共同特征是，来自固定的几台设备。当你在搜索服务上加一个针对设备ID 的限流功能之后，凌晨的高峰搜索请求不见了。但是不久之后，用户服务也出现了大量爬取用户信息的请求，商品接口出现了
2021-11-02 10:06:59
589
原创 高并发系统设计二十四（负载均衡）
在前面的基础篇中，我提到了高并发系统设计的三个通用方法：缓存、异步和横向扩展，到目前为止，你接触到了缓存的使用姿势，也了解了，如何使用消息队列异步处理业务逻辑，那么本节，我们一起了解一下，如何提升系统的横向扩展能力。在之前的课程中，我也提到过提升系统横向扩展能力的一些案例。比如，第八节提到，可以通过部署多个从库的方式，来提升数据库的扩展能力，从而提升数据库的查询性能，那么就需要借助组件，将查询数据库的请求，按照一些既定的策略分配到多个从库上，这是负载均衡服务器所起的作用，而我们一般使用 DNS 服务器来承
2021-10-29 11:06:52
1009
原创 高并发系统设计二十三（分布式Trace）
经过前面几节的学习，你的垂直电商系统在引入 RPC 框架，和注册中心之后已经完成基本的服务化拆分了，系统架构也有了改变：现在，你的系统运行平稳，老板很高兴，你也安心了很多。而且你认为，在经过了服务化拆分之后，服务的可扩展性增强了很多，可以通过横向扩展服务节点的方式，进行平滑地扩容了，对于应对峰值流量也更有信心了。但是这时出现了问题：你通过监控发现，系统的核心下单接口在晚高峰的时候，会有少量的慢请求，用户也投诉在 APP 上下单时，等待的时间比较长。而下单的过程可能会调用多个RPC 服务，或者使用多个资
2021-10-27 15:04:16
393
原创 高并发系统设计二十二（注册中心）
上一节，我们一起了解了 RPC 框架实现中的一些关键的点，你通过 RPC 框架，能够解决服务之间，跨网络通信的问题，这就完成了微服务化改造的基础。但是在服务拆分之后，你需要维护更多的细粒度的服务，而你需要面对的第一个问题就是，如何让 RPC 客户端知道服务端部署的地址，这就是我们今天要讲到的，服务注册与发现的问题。你所知道的服务发现服务注册和发现不是一个新的概念，你在之前的实际项目中也一定了解过，只是你可能没怎么注意罢了。比如说，你知道 Nginx 是一个反向代理组件，那么 Nginx 需要知道，应用
2021-10-27 10:58:02
252
原创 高并发系统设计二十一（RPC）
在前面两节中，你的团队已经决定对垂直电商系统做服务化拆分，以便解决扩展性和研发成本高的问题。与此同时，你们在不断学习的过程中还发现，系统做了服务化拆分之后，会引入一些新的问题，这些问题我在上节课提到过，归纳起来主要是两点：服务拆分单独部署后，引入的服务跨网络通信的问题；在拆分成多个小服务之后，服务如何治理的问题。如果想要解决这两方面问题，你需要了解，微服务化所需要的中间件的基本原理，和使用技巧，那么本节，我们一起了解，解决第一点问题的核心组件：RPC 框架。来思考这样一个场景：你的垂直电商系统的
2021-10-27 10:39:35
404
原创 高并发系统设计二十（单体架构做服务化改造）
上一节，我们了解了，单体架构向微服务化架构演进的原因，你应该了解到，当系统依赖资源的扩展性出现问题，或者是一体化架构带来的研发成本、部署成本变得难以接受时，我们会考虑对整体系统，做微服务化拆分。微服务化之后，垂直电商系统的架构会将变成下面这样：在这个架构中，我们将用户、订单和商品相关的逻辑，抽取成服务独立的部署，原本的Web 工程和队列处理程序，将不再直接依赖缓存和数据库，而是通过调用服务接口，查询存储中的信息。有了构思和期望之后，为了将服务化拆分尽快落地，你们决定抽调主力研发同学，共同制定拆分计划
2021-10-21 20:29:40
439
原创 高并发系统设计十九（走上服务化之路）
通过前面几个篇章的内容，你已经从数据库、缓存和消息队列的角度对自己的垂直电商系统在性能、可用性和扩展性上做了优化。现在，你的系统运行稳定，好评不断，每天高峰期的流量，已经达到了 10000/s 请求，DAU 也涨到了几十万。CEO 非常高兴，打算继续完善产品功能，以便进行新一轮的运营推广，争取在下个双十一可以将 DAU 冲击过百万。于是，你重新审视了自己的系统架构，分析系统中有哪些可以优化的点。目前来看，工程的部署方式还是采用一体化架构，也就是说所有的功能模块，比方说电商系统中的订单模块、用户模块、
2021-10-21 11:48:53
111
原创 高并发系统设计十八（消息积压）
看完前面两节之后，相信你对在垂直电商项目中，如何使用消息队列应对秒杀时的峰值流量已经有所了解。当然了，你也应该知道要如何做，才能保证消息不会丢失，尽量避免消息重复带来的影响。那么我想让你思考一下：除了这些内容，你在使用消息队列时还需要关注哪些点呢？先来看一个场景：在你的垂直电商项目中，你会在用户下单支付之后，向消息队列里面发送一条消息，队列处理程序消费了消息后，会增加用户的积分，或者给用户发送优惠券。那么用户在下单之后，等待几分钟或者十几分钟拿到积分和优惠券是可以接受的，但是一旦消息队列出现大量堆积，用户
2021-10-21 11:12:54
424
原创 高并发系统设计十七（关于消息重复消费）
经过上一节，我们在电商系统中增加了消息队列，用它来对峰值写流量做削峰填谷，对次要的业务逻辑做异步处理，对不同的系统模块做解耦合。因为业务逻辑从同步代码中移除了，所以，我们也要有相应的队列处理程序来处理消息、执行业务逻辑，这时，你的系统架构变成了下面的样子：这是一个简化版的架构图，实际上，随着业务逻辑越来越复杂，会引入更多的外部系统和服务来解决业务上的问题。比如说，我们会引入 Elasticsearch 来解决商品和店铺搜索的问题，也会引入审核系统，来对售卖的商品、用户的评论做自动的和人工的审核，你会越来
2021-10-19 20:04:51
276
原创 高并发系统设计十六（消息队列削峰）
在前面章节，我们了解了高并发系统设计的三个目标：性能、可用性和可扩展性，而在提升系统性能方面，我们一直关注的是系统的查询性能。也用了很多的篇幅去讲解数据库的分布式改造，各类缓存的原理和使用技巧。究其原因在于，我们遇到的大部分场景都是读多写少，尤其是在一个系统的初级阶段。比如说，一个社区的系统初期一定是只有少量的种子用户在生产内容，而大部分的用户都在“围观”别人在说什么。此时，整体的流量比较小，而写流量可能只占整体流量的百分之一，那么即使整体的 QPS 到了 10000 次 / 秒，写请求也只是到了每秒 1
2021-10-19 16:29:30
2284
1
原创 高并发系统设计十五（CDN技术）
前面几节我们了解了缓存的定义以及常用缓存的使用姿势，现在，你应该对包括本地缓存、分布式缓存等缓存组件的适用场景和使用技巧有了一定了解了。结合在14 讲中我提到的客户端高可用方案，你会将单个缓存节点扩展为高可用的缓存集群，现在，你的电商系统架构演变成了下面这样：在这个架构中我们使用分布式缓存对动态请求数据的读取做了加速，但是在我们的系统中存在着大量的静态资源请求：1、对于移动 APP 来说，这些静态资源主要是图片、视频和流媒体信息。2、对于 Web 网站来说，则包括了 JavaScript 文件，C
2021-10-06 18:23:20
540
原创 高并发系统设计十四（缓存穿透）
对于缓存来说，命中率是它的生命线。在低缓存命中率的系统中，大量查询商品信息的请求会穿透缓存到数据库，因为数据库对于并发的承受能力是比较脆弱的。一旦数据库承受不了用户大量刷新商品页面、定向搜索衣服信息，就会导致查询变慢，导致大量的请求阻塞在数据库查询上，造成应用服务器的连接和线程资源被占满，最终导致你的电商系统崩溃。一般来说，我们的核心缓存的命中率要保持在 99% 以上，非核心缓存的命中率也要尽量保证在 90%，如果低于这个标准，那么你可能就需要优化缓存的使用方式了。既然缓存的穿透会带来如此大的
2021-10-06 18:00:55
147
原创 高并发系统设计十三（缓存高可用）
前面几节，我们了解了缓存的原理、分类以及常用缓存的使用技巧。我们开始用缓存承担大部分的读压力，从而缓解数据库的查询压力，在提升性能的同时保证系统的稳定性。这时，你的电商系统整体的架构演变成下图的样子：我们在 Web 层和数据库层之间增加了缓存层，请求会首先查询缓存，只有当缓存中没有需要的数据时才会查询数据库。在这里，你需要关注缓存命中率这个指标（缓存命中率 = 命中缓存的请求数 / 总请求数）。一般来说，在你的电商系统中，核心缓存的命中率需要维持在 99% 甚至是 99.9%，哪怕下降 1%，系统都会
2021-09-13 23:51:22
208
原创 高并发系统设计十二（缓存读写策略）
上节，我们了解了缓存的定义、分类以及不足，你现在应该对缓存有了初步的认知。从今天开始，我们一起了解一下使用缓存的正确姿势，比如缓存的读写策略是什么样的，如何做到缓存的高可用以及如何应对缓存穿透。通过了解这些内容，你会对缓存的使用有深刻的认识，这样在实际工作中就可以在缓存使用上游刃有余了。今天，我们先讲讲缓存的读写策略。你可能觉得缓存的读写很简单，只需要优先读缓存，缓存不命中就从数据库查询，查询到了就回种缓存。实际上，针对不同的业务场景，缓存的读写策略也是不同的。而我们在选择策略时也需要考虑诸多的因素，比
2021-09-10 23:59:23
288
原创 高并发系统设计十一（缓存加速）
通过前面数据库篇的学习，你已经了解了在高并发大流量下，数据库层的演进过程以及库表设计上的考虑点。你的垂直电商系统在完成了对数据库的主从分离和分库分表之后，已经可以支撑十几万 DAU 了，整体系统的架构也变成了下面这样：从整体上看，数据库分了主库和从库，数据也被切分到多个数据库节点上。但随着并发的增加，存储数据量的增多，数据库的磁盘 IO 逐渐成了系统的瓶颈，我们需要一种访问更快的组件来降低请求响应时间，提升整体系统性能。这时我们就会使用缓存。那么什么是缓存，我们又该如何将它的优势最大化呢？本节课是缓存
2021-09-10 23:41:09
399
原创 高并发系统设计十（数据库优化--数据库与NoSQL互补）
前几节，我们了解了在你的垂直电商项目中，如何将传统的关系型数据库改造成分布式存储服务，以抵抗高并发和大流量的冲击。对于存储服务来说，我们一般会从两个方面对它做改造：1、提升它的读写性能，尤其是读性能，因为我们面对的多是一些读多写少的产品。比方说，你离不开的微信朋友圈、微博和淘宝，都是查询 QPS 远远大于写入 QPS。2、增强它在存储上的扩展能力，从而应对大数据量的存储需求。我前面讲到的读写分离和分库分表就是从这两方面出发，改造传统的关系型数据库的，但仍有一些问题无法解决。比如，在微博项目中关系的
2021-09-07 23:25:15
339
原创 高并发系统设计九（数据库优化方案--全局唯一ID）
在前面两节中，我们了解了分布式存储两个核心问题：数据冗余和数据分片，以及在传统关系型数据库中是如何解决的。当我们面临高并发的查询数据请求时，可以使用主从读写分离的方式，部署多个从库分摊读压力；当存储的数据量达到瓶颈时，我们可以将数据分片存储在多个节点上，降低单个存储节点的存储压力，此时我们的架构变成了下面这个样子：你可以看到，我们通过分库分表和主从读写分离的方式解决了数据库的扩展性问题，但是在第八节我也提到过，数据库在分库分表之后，我们在使用数据库时存在的许多限制，比方说查询的时候必须带着分区键；一些聚
2021-09-07 23:11:45
638
1
原创 高并发系统设计八（数据库优化方案--分库分表）
前一节，我们了解了在高并发下数据库的一种优化方案：读写分离，它就是依靠主从复制的技术使得数据库实现了数据复制为多份，增强了抵抗大量并发读请求的能力，提升了数据库的查询性能的同时，也提升了数据的安全性，当某一个数据库节点，无论是主库还是从库发生故障时，我们还有其他的节点中存储着全量的数据，保证数据不会丢失。此时，你的电商系统的架构图变成了下面这样：这时，公司 CEO 突然传来一个好消息，运营推广持续带来了流量，你所设计的电商系统的订单量突破了五千万，订单数据都是单表存储的，你的压力倍增，因为无论是数据库的
2021-09-07 00:07:06
331
原创 高并发系统设计七（数据库优化方案--主从分离）
上一节，我们用池化技术解决了数据库连接复用的问题，这时，你的垂直电商系统虽然整体架构上没有变化，但是和数据库交互的过程有了变化，在你的 Web 工程和数据库之间增加了数据库连接池，减少了频繁创建连接的成本，从上节课的测试来看性能上可以提升80%。现在的架构图如下所示：此时，你的数据库还是单机部署，依据一些云厂商的 Benchmark 的结果，在 4 核 8G 的机器上运 MySQL 5.7 时，大概可以支撑 500 的 TPS 和 10000 的 QPS。这时，运营负责人说正在准备双十一活动，并且公司层
2021-09-06 23:53:53
277
原创 高并发系统设计六（池化技术）
来想象这样一个场景，一天，公司 CEO 把你叫到会议室，告诉你公司看到了一个新的商业机会，希望你能带领一名兄弟，迅速研发出一套面向某个垂直领域的电商系统。在人手紧张，时间不足的情况下，为了能够完成任务，你毫不犹豫地采用了最简单的架构：前端一台 Web 服务器运行业务代码，后端一台数据库服务器存储业务数据。这个架构图是我们每个人最熟悉的，最简单的架构原型，很多系统在一开始都是长这样的，只是随着业务复杂度的提高，架构做了叠加，然后看起来就越来越复杂了。再说回我们的垂直电商系统，系统一开始上线之后，虽然用
2021-09-05 23:32:48
364
原创 高并发系统设计五（怎样让系统易于扩展）
从架构设计上来说，高可扩展性是一个设计的指标，它表示可以通过增加机器的方式来线性提高系统的处理能力，从而承担更高的流量和并发。你可能会问：“在架构设计之初，为什么不预先考虑好使用多少台机器，支持现有的并发呢？”这个问题我在“高并发系统设计三”一文中提到过，答案是峰值的流量不可控。一般来说，基于成本考虑，在业务平稳期，我们会预留 30%～50% 的冗余以应对运营活动或者推广可能带来的峰值流量，但是当有一个突发事件发生时，流量可能瞬间提升到 2～3倍甚至更高，我们还是以微博为例。鹿晗和关晓彤互圈公布恋情，
2021-09-03 00:05:57
279
原创 高并发系统设计四（系统怎样做到高可用）
高可用性（High Availability，HA）是你在系统设计时经常会听到的一个名词，它指的是系统具备较高的无故障运行的能力。我们在很多开源组件的文档中看到的 HA 方案就是提升组件可用性，让系统免于宕机无法服务的方案。比如，你知道 Hadoop 1.0 中的 NameNode 是单点的，一旦发生故障则整个集群就会不可用；而在 Hadoop2 中提出的 NameNode HA 方案就是同时启动两个NameNode，一个处于 Active 状态，另一个处于 Standby 状态，两者共享存储，一旦Act
2021-09-01 23:15:35
683
原创 高并发系统设计三（提升性能）
提到互联网系统设计，你可能听到最多的词儿就是“三高”，也就是“高并发”“高性能”“高可用”，它们是互联网系统架构设计永恒的主题。在前两节课中，我带你了解了高并发系统设计的含义，意义以及分层设计原则，接下来，我想带你整体了解一下高并发系统设计的目标，然后在此基础上，进入我们今天的话题：如何提升系统的性能？高并发系统设计的三大目标：高性能、高可用、可扩展高并发，是指运用设计手段让系统能够处理更多的用户并发请求，也就是承担更大的流量。它是一切架构设计的背景和前提，脱离了它去谈性能和可用性是没有意义的。很显然
2021-08-31 23:33:12
1197
原创 高并发系统设计二（架构分层）
在系统从 0 到 1 的阶段，为了让系统快速上线，我们通常是不考虑分层的。但是随着业务越来越复杂，大量的代码纠缠在一起，会出现逻辑不清晰、各模块相互依赖、代码扩展性差、改动一处就牵一发而动全身等问题。这时，对系统进行分层就会被提上日程，那么我们要如何对架构进行分层？架构分层和高并发架构设计又有什么关系呢？本节课，我将带你寻找答案。什么是分层架构软件架构分层在软件工程中是一种常见的设计方式，它是将整体系统拆分成 N 个层次，每个层次有独立的职责，多个层次协同提供完整的功能。我们在刚刚成为程序员的时候，
2021-08-30 23:55:27
1202
4
原创 高并发系统设计一
我们知道，高并发代表着大流量，高并发系统设计的魅力就在于我们能够凭借自己的聪明才智设计巧妙的方案，从而抵抗巨大流量的冲击，带给用户更好的使用体验。这些方案好似能操纵流量，让流量更加平稳得被系统中的服务和组件处理。来做个简单的比喻吧。从古至今，长江和黄河流域水患不断，远古时期，大禹曾拓宽河道，清除淤沙让流水更加顺畅；都江堰作为史上最成功的的治水案例之一，用引流将岷江之水分流到多个支流中，以分担水流压力；三门峡和葛洲坝通过建造水库将水引入水库先存储起来，然后再想办法把水库中的水缓缓地排出去，以此提高下游的抗
2021-08-30 23:38:16
286
1
原创 利用策略模式优化代码的if else
利用策略模式优化代码的if else今天我们来说说如何利用策略模式重构我们代码中的if else1、我们本着高内聚低耦合的设计理念，将ifelse中的代码剥离出来，下面我们首先声明一个接口方法：/** * 策略模式接口 * * @author fengjie song * */public interface IStrategyPattern { /** * ifels...
2019-11-10 10:22:11
398
原创 redis分布式锁的设计
redis分布式锁的设计今天我们来说一说基于redis分布式锁的设计（基于springboot框架下的实现）：1、首先我们设计一个接口：/** * 分布式锁 * * @author fengjie song * */public interface DistributedLock { /** * 分布式锁1 * * @param key * @return...
2019-11-10 08:58:55
509
转载 Oracle函数大全
F.1字符函数——返回字符值(chr,concat,initcap,lower,lpad/rpad,nls_initcap,nls_lower,nls_upper,regexp_replace,regexp_substr,replace,trim/ltrim/rtrim,soundex,substr,translate,upper)说明：可以sql和plsql中使用CHR语法: chr(...
2019-03-27 20:01:24
500
转载 Linux查看日志常用命令
1.查看日志常用命令tail: -n 是显示行号；相当于nl命令；例子如下： tail -100f test.log 实时监控100行日志 tail -n 10 test.log 查询日志尾部最后10行的日志; tail -n +10 test.log 查询10行之后的所有日志;head: ...
2019-03-26 13:42:10
1479
原创 一篇文章读懂java8新特性（lambda、stream）用法
import java.util.ArrayList;import java.util.Arrays;import java.util.Collection;import java.util.List;import java.util.Optional;import java.util.function.Predicate;import java.util.function.ToInt...
2019-03-25 20:55:39
113
原创 ShedLock锁，防止spring定时调度@Scheduled注解在分布式环境下重复执行
多个微服务，其业务的逻辑是一样的，自然包括定时任务。负载均衡在执行的时候，到达某个节点以后，定时任务都会执行，可以控制的思路就是使用队列的方式去操作。如下有两种思路：将负载均衡的定时任务，从原先的直接执行业务逻辑修改为先将业务逻辑请求到队列中，然后让空闲的微服务去队列中自动领取；将负载均衡的定时任务，加锁进行操作。ShedLockShedLock就是一种巧妙使用锁的方式的，在GitHub...
2019-02-15 17:59:07
7669
1
原创 文件与base64编码互相转换
import java.io.BufferedOutputStream;import java.io.File;import java.io.FileNotFoundException;import java.io.FileOutputStream;import java.io.IOException;import java.io.InputStream;import java.nio...
2018-12-04 14:03:36
2988
原创 list根据任意泛型的属性去重工具类
public class Test {public static void main(String[] args) throws Exception{ List<Student> list = new ArrayList<Student>(); Student stu1 = new Student("1", "zhangsan"); Student stu2 = ...
2018-12-04 11:16:11
503
mac安装brew出现报错：
2023-09-13
TA创建的收藏夹 TA关注的收藏夹
TA关注的人