246 天前 / 苏溪云
自上一篇写关于 diff 的文章到现在已经过了二十天多，利用业余时间和 10 天婚假的闲暇，终于搞懂了 React 源码中的调度原理。当费劲一番周折终于调试到将更新与调度任务连接在一起的核心逻辑那一刻，忧愁的嘴角终于露出欣慰的微笑。 最早之前，React 还没有用 fiber 重写，那个时候对 React 调度模块就有好奇。而现在的调度模块对于之前没研究过它的我来说更是带有一层神秘的色彩，色彩中朦胧浮现出两个字：“困难”。
362 天前 / kuzan07
另外在概念层面，本篇文章希望能够解释清楚 reactor 领域一些常见的概念在实践层面，带读者体验一下 reactor 模式的写法，抛砖引玉 案例实现还是 promise 文章里的案例：基于计算器服务，实现一个接口，接口实现计算 a + ((b -c）+ d) -e -f + g 本文实现依然是基于 vertx 和 kotlin 来做，只是异步结果编排部分替换为 reactor 实现： class ReactorVerticle : AbstractVerticle(){lateinit var webClient: WebClientoverride fun start() {webClient = WebClient.create(vertx)var eventBus = vertx.eventBus()eventBus.consumer("calc.reactor"){ msg ->...
370 天前 / kuzan07
本文主要聊一聊异步编程中的 promise 模式；promise 模式广泛应用于前端开发，所以故事先从前端开发讲起。因为前端的 ajax 技术，与服务端通信皆是基于异步编程，需要处理各种回调；回调本身并不可怕，但是如果需要对多个回调结果进行 compose， 那就比较麻烦了，会出现所谓的回调地狱；在异步编程方面，前端同学先痛起来了，所以，在这个方向上，前端同学确实走的也比较靠前，模式也比较成熟。那么对于 java 而言，先不谈协程的玩法，异步编程可选的模式就不多了，其中一个便是 promise 模式，以及接下来会进行介绍的 reactor 模式。
486 天前 / 涯之叶
最近中台的文章比较多，大多数谈历史，谈原因，之后就是谈技术了，但是中台真的实施起来，却躲不开下面的灵魂拷问。 问题一：到底哪些应该作为中台，哪些不应该作为中台，是谁决定的？如何决定的？ 问题二：每一个中台应该有哪些功能？谁来定义？和业务方如何切分？怎样保证切分的合理？每一个中台应该有多大？按接口数？代码行数？什么时候决定再拆分？谁决定？ 问题三：维护每一个中台的团队应该有多大？10个人？100人？用户中心和商品中心应该哪个人多哪个人少？什么时候能扩招？谁来定？绩效如何？谁来定？ 问题四：和业务方的...
500 天前 / 知了一笑
一、Cache缓存简介从Spring3开始定义Cache和CacheManager接口来统一不同的缓存技术； Cache接口为缓存的组件规范定义，包含缓存的各种操作集合； Cache接口下Spring提供了各种缓存的实现； 如RedisCache，EhCacheCache ,ConcurrentMapCache等； 二、核心API说明1、Cache缓存接口 定义缓存操作。实现有：RedisCache、EhCacheCache、ConcurrentMapCache等 2、CacheManager 缓存管理器，管理各种缓存（cache）组件 3、@Cacheable 主要针对方法配置，能够根据方法的请求参数对其进行缓存 Cacheable执行流程 1）方法运行之前...
516 天前 / GO语言中文网
写代码难，写处理并行和并发的代码更难！要做到这一切并保持高效将是极具挑战性的。 今天，我决定开始分享一些技巧来处理某些特殊情况。 定时 Channel 操作有时，你想要为你的 Channel 操作定时：持续尝试做一些事情，如果不能在一段时间内完成就放弃继续尝试。 要做到这一点，你可以使用 context 或者 time，两者都很好。context可能更惯用，而 time 则更高效，但它们几乎是完全相同的： 1funcToChanTimedContext(ctxcontext.Context,dtime.Duration,messageType,cchan<-Type)(writtenbool){ 2ctx,cancel:=context.WithTimeout(ctx,d) 3defercanc...
527 天前 / 蚂蚁金服分布式架构SOFAStack
作者：屹远（陈龙），蚂蚁金服分布式事务核心研发 。本文根据 8月11日 SOFA Meetup#3 广州站 《分布式事务 Seata 及其三种模式详解》主题分享整理，着重分享分布式事务产生的背景、理论基础，以及 Seata 分布式事务的原理以及三种模式（AT、TCC、Saga）的分布式事务实现。现场回顾视频以及 PPT 见文末链接。| 分布式事务产生的背景1.1 分布式架构演进之 -数据库的水平拆分蚂蚁金服的业务数据库起初是单库单表，但随着业务数据规模的快速发展，数据量越来越大，单库单表逐渐成为瓶颈。所以我们对数据库进行了水平拆分，将原单库单表拆分成数据库分片。
540 天前 / 张铁蕾
前言 我来自于AI Labs运营平台，这些年陆续实现了不少运营需求；在做的过程中，一直在思考运营平台的能力建设问题。 对于业务来说，如何更自然的划分业务与运营平台的边界，简化两边的合作模式；对于运营平台来说，如何快速沉淀运营知识与能力，赋能各个业务方；对于运营人员来说，有没有一种直观的运营能力地图，可以一目了然的查看整个业务板块的可干预功能。 在这个万物互联向前大步推进的新时代，我们已经有了数据互联、服务互联，作为这一切的根基，有没有代码互联？ 扩展点尝试着回答以上的问题。
587 天前 / 个推技术学院
作者：个推数据研发工程师 学长 1业务背景随着大数据的快速发展，业务场景越来越复杂，离线式的批处理框架MapReduce已经不能满足业务，大量的场景需要实时的数据处理结果来进行分析、决策。Spark Streaming是一种分布式的大数据实时计算框架，他提供了动态的，高吞吐量的，可容错的流式数据处理，不仅可以实现用户行为分析，还能在金融、舆情分析、网络监控等方面发挥作用。个推开发者服务——消息推送“应景推送”正是应用了Spark Streaming技术，基于大数据分析人群属性，同时利用LBS地理围栏技术，实时触发精准消息推送，实现用户的精细化运营。
596 天前 / 郭茄茄
点击上方蓝色文字“后端技术小黑屋”，关注茄子拯救世界的公众号吧~ 相信大家在阅读C++代码的时候，一定都见过pImpl的实现方式。我第一次见到pImpl实现方式时，对于下面这种代码： void MyClass::SomeFunc() { pImpl_->SomeFunc();}总有一种“脱了裤子放屁”的感觉。而对于经常提到的pImpl模式的优点，什么“屏蔽私有接口”，什么“增加封装性”，又觉得虚之又虚——我这系统要么给自己部门用的，要么是要开源的，有啥见不得人的，要屏蔽呢？多增加了一层pImpl也没见得封装性有什么提升啊？ 其实，pImpl模式既然应用如此广泛，必然有其价值。
605 天前 / 雪花男孩
点击蓝色“乔志勇笔记”关注我哟 加个“星标”，第一时间获取推送的文章哦 一、高性能数据库集群 （1）读写分离主从复制延迟 1、写操作后的读操作指定发给数据库主服务器 2、读从机失败后再读一次主机 3、关键业务读写操作全部指向主机，非关键业务采用读写分离 分配机制 1、程序代码分装 2、中间件封装 (2)分库分表二、高性能nosqlK-V 存储：解决关系数据库无法存储数据结构的问题，以 Redis 为代表。 文档数据库：解决关系数据库强 schema 约束的问题，以 MongoDB 为代表。
611 天前 / 杭州小布
redis cluster是redis提供的集群模式。 1.redis cluster的架构①可以有多个master node，每个master node 都可以挂载多个slave node。 ②读写分离的架构，对应每个master node来说，写就写到master node，读就从master node对应的slave node去读。 ③高可用。每个master node都有多个 slave node，如果master node挂了，redis cluster机制就会自动将某个slave node切换成 master node。 所以redis cluster是 多master + 读写分离 + 高可用 的。
641 天前 / 蚂蚁金服分布式架构SOFAStack
650 天前 / 非典型前端coder
原文链接 大家好。我带着一篇新的关于Flutter的文章回来了。这一次，我将向你展示“如何架构你的Flutter项目”。这样您就可以轻松维护，扩展和测试Flutter项目。在深入探讨实际话题之前。我想分享一个小故事，说明为什么我们应该专注于为我们的项目构建一个坚实的架构。 更新：本文的第2部分已发布，当前设计中有一些更改，以解决一些问题并展示一些惊人的实现。链接在这里。 为什么你需要对你的项目进行架构多年前的2015年，我是还是一名求胜心切的新手程序员，当时我在学习Android应用程序开发。
663 天前 / 崔秀龙
原作者：Sonya Koptyev 原标题：Why a Microservices Hybrid Model Is What You Probably Need Instead 在听到别人谈及微服务的时候，你会注意到他们讨论的是一个非此即彼的问题：重构成微服务？还是固守单体形态？这种想法很合情理：微服务是个复杂的话题，把这个复杂性简化成一个二选一问题，就轻松了。 然而微服务实际上并不是一个非黑即白的概念。在应用中部分使用微服务，其它组件仍然保持单体应用的状态，这是一种完全有可能的情况。 这就成了一种混合模式的微服务。