Surlymo
- 浏览: 97197 次
- 性别:
- 来自: 北京
-
最新评论
-
Surlymo：
kidding87 写道还得看sdk，Memcached的sd ...
memcached限制以及与reids的比较 -
kidding87：
还得看sdk，Memcached的sdk写的不怎么样，goog ...
memcached限制以及与reids的比较 -
Surlymo：
jiaofuyou 写道想问个问题，象这种任务分发的工作队列， ...
rabbitmq学习笔记 -
jiaofuyou：
想问个问题，象这种任务分发的工作队列，你举的例子是一个队列被多 ...
rabbitmq学习笔记 -
Surlymo：
lijunlong 写道用CountDownLatch呢这个一 ...
ThreadPoolExecutor和CyclicBarrier配合使用可能带来的隐患
文章列表
https://blog.csdn.net/surlymo/article/details/82191875
关于Servicemesh是什么，能做什么，此处不再进行赘述，相关文章已经非常之多。读者可以自行上网查阅。Servicemesh是一个比较新的名词，在2017年才逐步传播开来。之前主要集中于各种云服务的解决方案中使用。我们在开始阐述Servicemesh之前，先来系统地回顾下微服务的发展历程，其更有助于我们对Servicemesh的了解。以下会根据我实际的经验，以及一些方法论，来穿插推进论证整个发展历程。
1.1 MVP阶段
在初始阶段，为了追求最高效率的快速试错和产品迭代，几乎所有的公司的技术架构最开始都是这么演进过来的。从自身经历来，举几个例子。
百度凤巢。百度广告系统。主系统 ...
开篇明义：
【大型网站技术架构笔记】系列是阅读《大型网站技术架构核心原理与实践》一书的一些笔记，记录了原书的一些重要内容以及我的个人理解。其中很多内容网上都能找得到。其实整本书，我最赞同的是作者阐述的网站架构的价值观——“业务成就技术，而不是相反”。在没有业务场景的时候就一味追逐架构，为技术而技术，或者一上来就想要设计出一个可以适用所有场景的解决方案，是不理智的。我们有的时候可能会陷入技术的怪圈而忘了考虑业务本身。我曾经看到的一句我很喜欢的话，在这边也与诸君分享：好的架构都是进化来的，不是设计来的。
以下为 （一）演化过程 内容：
一、初始阶段
初始阶段考虑到使用量规范较 ...
1、JDK和JRE的区别JDK是开发库，而JRE只是运行环境。JRE没有编译器，也没有JAVA API里面非JAVASE API的部分等。eclipse之所以用jre也能运行，是因为IDE内部集成了编译器。2、运行时数据区域（1）程序计数器（program counter register） ...
一、zookeeper
1、实现原理：
基于zookeeper瞬时有序节点实现的分布式锁，其主要逻辑如下（该图来自于IBM网站）。大致思想即为：每个客户端对某个功能加锁时，在zookeeper上的与该功能对应的指定节点的目录下，生成一个唯一的瞬时有序节点。判断是否获取锁的方式很简单，只需要判断有序节点中序号最小的一个。当释放锁的时候，只需将这个瞬时节点删除即可。同时，其可以避免服务宕机导致的锁无法释放，而产生的死锁问题。
2、优点
锁安全性高，zk可持久化
3、缺点
性能开销比较高。因为其需要动态产生、销毁瞬时节点来实现锁功能。
4、实现
可以直接采用zookeeper第三方库 ...
一、memcached限制
在分布式企业级应用中，memcached被广泛使用。但是关于它自身的一些限制需要我们了解：1、过期时间memcached的缓存策略为：失效时间 + LRU(最近最少使用)。其过期时间设置上限阈值为30天，若超过30天后，将获取不到存储的数据。2、数据稳定性memcached需要保证集群的内存空间足够大，否则内存满了之后，会采用LRU置换算法，将部分数据清除，加上其无法进行持久化，所以将导致数据丢失。3、存储限制键被限制在250字符之内。而且由于memcached默认采用了slab内存分配机制，所以单个数据项不能超过 1M。memcached没有采用malloc/ ...
在公司项目中对单测框架做升级的时候，引入了h2数据库，同时希望每个case在访问h2做读写操作之后，不会影响下一个case对h2的数据访问。
1、最先想到的肯定是dbunit和unitils，但经过调研，发现和现有单测框架存在测试入口 ...
前一阵子写SEDA异步框架的时候，使用了rabbitmq作为分布式消息队列（见前文），把一些学习官网教程的笔记简单备忘。示例都来自官网
Part 2 Work Queues
1、round-robin dispatchering
缺陷：存在不能准确负载均衡的弊端
2、fair dispatch --> 针对管道
采用channel.basicQos(prefetchCount); 缺陷：可能带来队列塞
3、message acknowledge --> 针对消费者
boolean autoAck = false;channel.basicCon ...
在敏捷开发中，随着文档地位不断被削弱，此时代码的可读性和质量往往成为直接决定项目是否健壮可维护的关键。这就要求我们的代码具有良好的风格（包括注释、命名等）、代码格式标准、程序没有非法调用和低级bug，以及用以对功能进行解释的单元测试能够尽可能多地覆盖核心功能。如果每次我们都手动去依次检查这些点是否达标，那持续集成将变得无比缓慢。更遑论持续交付了。
所以在持续集成（CI）的过程中，每次local build的时候，我们可以利用一些maven插件对代码进行以上需求的自动化校准或校验。宥于时间，所以此处不能对每个插件的使用进行详细说明。以后有时间会进行详细整理。以下我们依次进行简 ...
基于SEDA的异步框架设计与实现
四、异步框架总体设计与实现
1、框架中的stage理想结构
前文提到，基于SEDA的异步框架，一个stage的理想结构描述如下：
在这个框架的设想中，一个stage一般需要有如下几个组件：
1、D-MQ：分布式消息中间件。用做事件队列，以进行消息的传递。
2、Local-Queue：本地队列。一般是blockingQueue，用以辅助实现stage内的动态线程池。采用Local-Queue的目的在于避免数据在mq中的堆积导致mq性能下降。
3、Thread ...
基于SEDA的异步框架设计与实现
三、异步框架技术选型
在这次实现的SEDA异步框架中，采用的基础架构原型如下：
采用了spring+quartz+fastjson+rabbitmq来实现。和传统SEDA架构区别比较大的地方在于：
1、采用分布式mq（使用了rabbitmq）而不是blockingqueue。如此既可以支持以后可能进行的分布式化扩展，也可以使得框架具有高可用性，在大数据处理的时候仍可具有较为客观的性能。同时，消息的传递过程中，采用了高性能的fastjson进行数据序列化和反序列化。使得数据在stage之间的传递速度更快。
...
基于SEDA的异步框架设计与实现
二、为什么使用SEDA
目前，面对并发环境，主流互联网服务器编程模型有两种：多线程模型以及事件驱动模型。但是这两个模型都不足以解决这个问题。我们来首先看一下这两种编程模型。
1、多线程并发模型
多线程并发模型是目前最普遍的服务器编程模型，该模型的架构如下图所示： 该模型针对每一个请求，会为其创建并分配一个线程。该线程负责这个请求的处理。该模型的优点：执行粒度是整个完整的处理流程。处理逻辑清晰，容易开发。但与此同时缺点也很明显：如果处理过程中某一步骤出现长时间调用（例如网络 ...
基于SEDA的异步框架设计与实现
一、SEDA国内外研究现状
1、SEDA架构的起源和特点 当前最流行的互联网服务器模型基本都是基于多线程／进程并发服务模型。然而当线程数目增加到一定值后，系统性能会下降，这就限 ...
安装了erl之后，在将rabbitmq搭建到linux服务器的时候，根据在windows搭建的经验，本以为可以几下搞定，结果启动不断地报错误（plugins启用了web管理界面），到google上找了一圈也没看到合理的解答，而其错误log为erlang的crash.dump文件，阅读起来太过困难。
后来才开始将怀疑点集中在内核、erlang以及rabbitmq的版本问题上。在更换内核到新版本AS6的版本之后。该问题就解决了。以下为其中一个错误case。以后如果有类似错误的时候，可以首先考虑下有没有可能是版本问题。
图省事在开发新系统的时候把老工程拿来改造，由于老工程有不少版本不一致的spring组件依赖，导致在加入新spring依赖的时候，各种jar包冲突，什么接口不能被初始化，什么找不到方法等等的。
比如
java.lang.NoSuchMethodError: org.springframework.context.support.AbstractRefreshableConfigApplicationContext.getEnvironment()Lorg/springframework/core/env/ConfigurableEnvironment;
而慢慢排查，排除冲突jar包、重新查 ...