首页 文章 精选 留言 我的

精选列表

搜索[分片调整]，共10004篇文章
优秀的个人博客,低调大师

Martian 4.0，架构大幅调整

Martian4.0 是啥 Martian4.0 是一个 最新的主线版本，内部架构产生了巨大的变化，之前的版本 里面大部分功能都是Martian自带的，属于一个高度内聚的项目。而从4.0开始 不再以这种方式进行开发了。 而是基于Magician开发，定位成一个Magician项目的超集，整合了Magician的大部分组件，并进行了少量的二次封装，使其可以快捷的构建后端服务。 4.x将会跟 3.x 并行维护，一直到3.x的用户都转到4.x 为止。 4.0 带来了哪些变化 一、AOP与IOC没了 为什么会这样的呢？ 因为Magician没有这两个特性，所以Martian自然也不会有了，加是可以加的，但是考虑到几个问题所以暂时不打算支持。 首先，IOC 和 new的区别 在于，IOC的对象是框架创建的，所以这个对象上可以被框架绑定很多功能，AOP就是其中一项，但是在实际开发中，IOC的作用体现的不是很明显，甚至很多场景都不需要IOC，尤其是注解式开发流行以后，IOC的优势就大大下滑了。 AOP，一般用的最多的就是 做声明式事务，其他场景很少用，而Magician 有类似的组件可以实现声明式事务，所以AOP 也不是特别的刚需了，如果真的需要可以自己用动态代理实现。 二、不再内置Jedis Jedis是redis的Java客户端，其本身已经封装的够强了，个人认为没必要再套个壳子了。比如，想要连接操作redis，只需要这样。 JedisPool jedisPool = new JedisPool(连接池, url, 端口, 超时时间, 用户名, 密码, 库索引, 是否ssl); Jedis jedis = jedisPool.getResource(); 这个代码量跟之前Martian封装过相比，相差并不大（连配置的代码也一起算上）。而且还不用专门学习怎么在Martian中连接redis，只需要直接用原生Jedis即可。 如果未来Magician 出了封装Jedis的模块，那么到时候会集成进来。 三、Controller支持路由配置 之前都是直接请求方法名的，现在由于是基于Magician开发的，所以Controller也支持路由自定义了，但是声明式API没了，不再支持。 @Route("/demoController") public class DemoController { @Route(value = "/demo", requestMethod = ReqMethod.POST) public DemoVO demo(DemoVO demoVO){ return demoVO; } } 四、定时任务没了 因为没了IOC所以 与其绑定的功能 自然也都没了。不过自己写也不难，JDK自带了定时任务的api。 // 2000毫秒执行一次 Timer timer = new Timer(); timer.schedule(new TimerTask() { public void run() { System.out.println("-------设定要指定任务--------"); } }, 2000);// 设定指定的时间time,此处为2000毫秒 后面会开发定时任务相关的组建，来弥补这个缺失。 五、暂时与Martian-cloud，Martian-gateway不兼容 考虑到项目规模太小，不太可能有人在用Martian开发微服务，所以这两个组件暂时不考虑兼容，后面再进行迭代 3.x 以后还会继续维护吗 当然会继续维护，不过 基本会以修bug为主，不再提供新功能了。一直维护到所有用户都转到了4.x为止。 而且大家也不用担心，4.x 不会简简单单的基于Magician的，后面会持续迭代，出更多功能的。其使用的便捷程度不会低于3.x，甚至会高于3.x。 而且Magician一旦出了新组建，将会被快速集成到Martian的。 Magician是啥 可以看这个官网了解一下哦：http://magician-io.com
2021-04-17
优秀的个人博客,低调大师

流量调整和限流技术

在早期的计算机领域，限流技术(time limiting)被用作控制网络接口收发通信数据的速率。 可以用来优化性能，减少延迟和提高带宽等。 现在在互联网领域，也借鉴了这个概念， 用来为服务控制请求的速率， 如果双十一的限流， 12306的抢票等。 即使在细粒度的软件架构中，也有类似的概念。 两种常用算法 令牌桶(Token Bucket)和漏桶(leaky bucket)是 最常用的两种限流的算法。 漏桶算法 它的主要目的是控制数据注入到网络的速率，平滑网络上的突发流量。漏桶算法提供了一种机制，通过它，突发流量可以被整形以便为网络提供一个稳定的流量。 漏桶可以看作是一个带有常量服务时间的单服务器队列，如果漏桶（包缓存）溢出，那么数据包会被丢弃。 用说人话的讲： 漏桶算法思路很简单，水（数据或者请求）先进入到漏桶里，漏桶以一定的速度出水，当水流入速度过大会直接溢出，可以看出漏桶算法能强行限制数据的传输速率。 在某些情况下，漏桶算法不能够有效地使用网络资源。因为漏桶的漏出速率是固定的参数，所以，即使网络中不存在资源冲突（没有发生拥塞），漏桶算法也不能使某一个单独的流突发到端口速率。因此，漏桶算法对于存在突发特性的流量来说缺乏效率。而令牌桶算法则能够满足这些具有突发特性的流量。通常，漏桶算法与令牌桶算法可以结合起来为网络流量提供更大的控制。 令牌桶算法 令牌桶算法的原理是系统会以一个恒定的速度往桶里放入令牌，而如果请求需要被处理，则需要先从桶里获取一个令牌，当桶里没有令牌可取时，则拒绝服务。 令牌桶的另外一个好处是可以方便的改变速度。 一旦需要提高速率，则按需提高放入桶中的令牌的速率。 一般会定时(比如100毫秒)往桶中增加一定数量的令牌， 有些变种算法则实时的计算应该增加的令牌的数量, 比如华为的专利"采用令牌漏桶进行报文限流的方法"(CN 1536815 A),提供了一种动态计算可用令牌数的方法， 相比其它定时增加令牌的方法， 它只在收到一个报文后，计算该报文与前一报文到来的时间间隔内向令牌漏桶内注入的令牌数， 并计算判断桶内的令牌数是否满足传送该报文的要求。 从最终用户访问安全的角度看，设想有人想暴力碰撞网站的用户密码；或者有人攻击某个很耗费资源的接口；或者有人想从某个接口大量抓取数据。大部分人都知道应该增加 Rate limiting，做请求频率限制。从安全角度，这个可能也是大部分能想到，但不一定去做的薄弱环节。 从整个架构的稳定性角度看，一般 SOA 架构的每个接口的有限资源的情况下，所能提供的单位时间服务能力是有限的。假如超过服务能力，一般会造成整个接口服务停顿，或者应用 Crash，或者带来连锁反应，将延迟传递给服务调用方造成整个系统的服务能力丧失。有必要在服务能力超限的情况下 Fail Fast。 另外，根据排队论，由于 API 接口服务具有延迟随着请求量提升迅速提升的特点，为了保证 SLA 的低延迟，需要控制单位时间的请求量。这也是 Little’s law 所说的。 还有，公开 API 接口服务，Rate limiting 应该是一个必备的功能，否则公开的接口不知道哪一天就会被服务调用方有意无意的打垮。 所以，提供资源能够支撑的服务，将过载请求快速抛弃对整个系统架构的稳定性非常重要。这就要求在应用层实现 Rate limiting 限制。 常见的 Rate limiting 的实现方式Proxy 层的实现，针对部分 URL 或者 API 接口进行访问频率限制 Nginx 模块 limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s; server { location /search/ { limit_req zone=one burst=5; } 详细参见： ngx_http_limit_req_module Haproxy 提供的功能 详细参见： Haproxy Rate limit 模块 RateLimiters是令牌桶和漏桶在.NET 中实现。这些策略可用于速率限制请求不同的网站中，后端或 API 调用等场景。 ASP.NET Web API rate limiter for IIS and Owin hosting 基于 Redis 功能的实现 这个在 Redis 官方文档有非常详细的实现。一般适用于所有类型的应用，比如 PHP、Python 等等。Redis 的实现方式可以支持分布式服务的访问频率的集中控制。Redis 的频率限制实现方式还适用于在应用中无法状态保存状态的场景。 参见：Redis INCR rate limiter 本文来自云栖社区合作伙伴“doNET跨平台”，了解相关信息可以关注“opendotnet”微信公众号
2017-07-31
优秀的个人博客,低调大师

RocketMQ 主题扩分片后遇到的坑

消息组接到某项目组反馈，topic 在扩容后出现部分队列无法被消费者，导致消息积压，影响线上业务？ 考虑到该问题是发送在真实的线上环境，为了避免泄密，本文先在笔者的虚拟机中来重现问题。 1、案情回顾 1.1 集群现状 集群信息如下：例如业务主体名 topic_dw_test_by_order_01 的路由信息如图所示：当前的消费者信息：broker 的配置信息如下： brokerClusterName = DefaultCluster brokerName = broker-a brokerId = 0 deleteWhen = 04 fileReservedTime = 48 brokerRole = ASYNC_MASTER flushDiskType = ASYNC_FLUSH brokerIP1=192.168.0.220 brokerIP2-192.168.0.220 namesrvAddr=192.168.0.221:9876;192.168.0.220:9876 storePathRootDir=/opt/application/rocketmq-all-4.5.2-bin-release/store storePathCommitLog=/opt/application/rocketmq-all-4.5.2-bin-release/store/commitlog autoCreateTopicEnable=false autoCreateSubscriptionGroup=false 备注：公司对 topic、消费组进行了严格的管控，项目组需要使用时需要向运维人员申请，故 broker 集群不允许自动创建主题与自动创建消费组。 由于该业务量稳步提升，项目组觉得该主题的队列数太少，不利于增加消费者来提高其消费能力，故向运维人员提出增加队列的需求。 1.2、RocketMQ 在线扩容队列 运维通过公司自研的消息运维平台，直接以指定集群的方式为 topic 扩容，该运维平台底层其实使用了RocketMQ 提供的 updateTopic 命令，其命令说明如下：从上图可以得知可以通过 -c 命令来指定在集群中所有的 broker 上创建队列，在本例中，将队列数从 4 设置为 8，具体命令如下： sh ./mqadmin upateTopic -n 192.168.0.220:9876 -c DefaultCluster -t topic_dw_test_by_order_01 -r 8 -w 8 执行效果如图所示，表示更新成功。我们再来从 rocketmq-console 中来看命令执行后的效果：从上图可以得知，主题的队列数已经扩容到了8个，并且在集群的两台broker上都创建了队列。 1.3 消息发送 从 RocketMQ 系列可知，RocketMQ 是支持在线 topic 在线扩容机制的，故无需重启 消息发送者、消息消费者，随着时间的推移，我们可以查看topic的所有队列都参与到了消息的负载中，如图所示：我们可以清晰的看到，所有的16个队列(每个 broker 8个队列)都参与到了消息发送的，运维小哥愉快的完成了topic的扩容。 2、问题暴露 该 topic 被 5个消费组所订阅，突然接到通知，其中有两个消费组反馈，部分队列的消息没有被消费，导致下游系统并没有及时处理。 3、问题分析 当时到项目组提交到消息组时，我第一反应是先看消费者的队列，打开该主题的消费情况，如图所示：发现队列数并没有积压，备注（由于生产是4主4从，每一个 broker上8个队列，故总共32个队列），当时由于比较急，并没有第一时间发现这个界面，竟然只包含一个消费者，觉得并没有消息积压，又由于同一个集群，其他消费组没有问题，只有两个消费组有问题，怀疑是应用的问题，就采取了重启，打印线程栈等方法。 事后诸葛亮：其实这完成是错误的，为什么这样说呢？因为项目组（业务方）已经告知一部分业务未处理，说明肯定有队列的消息积压，当根据自己的知识，结合看到的监控页面做出的判断与业务方反馈的出现冲突时，一定是自己的判断出了问题。 正在我们“如火如荼”的认定是项目有问题时，团队的另一成员提出了自己的观点，原来在得到业务方反馈时，他得知同一个主题，被5个消费组订阅，只有其中两个有问题，那他通过rocketmq-console来找两者的区别，找到区别，找到规律，就离解决问题的路近了。 他通过对比发现，出问题的消费组只有两个客户端在消费（通常生产环境是4节点消费），而没有出现问题的发现有4个进程都在处理，即发现现象：出错的消费组，并没有全员参与到消费。正如上面的图所示：只有其中一个进程在处理8个队列，另外8个队列并没有在消费。 那现在就是要分析为啥topic共有16个队列，但这里只有1个消费者队列在消费，另外一个消费者不作为？ 首先根据RocketMQ 消息队列负载机制，2个消费者，只有1个消费者在消费，并且一个有一个明显的特点是，只有broker-a上的队列在消费，broker-b上的队列一个也没消费。 正在思考为啥会出现这种现象时，他又在思考是不是集群是不是broker-b(对应我们生产环境是broker-c、broker-d上的队列都未消费)是新扩容的机器？扩容的时候是不是没有把订阅关系在新的集群上创建？提出了疑问，接下来肖工就开始验证猜想，通过查阅broker-c、broker-d在我们系统中创建的时间是2018-4月的时候，就基本得出结论，扩容时并没有在新集群上创建订阅消息，故无法消费消息。 于是运维小哥使用运维工具创建订阅组，创建方法如图所示：创建好消费组后，再去查看topic的消费情况时，另外一个消费组也开始处理消息了，如下图所示： 4、问题复盘 潜在原因：DefaultCluster 集群进行过一次集群扩容，从原来的一台消息服务器( broker-a )额外增加一台broker服务器( broker-b )，但扩容的时候并没有把原先的存在于 broker-a 上的主题、消费组扩容到 broker-b 服务器。 触发原因：接到项目组的扩容需求，将集群队列数从4个扩容到8个，这样该topic就在集群的a、b都会存在8个队列，但Broker不允许自动创建消费组（订阅关系），消费者无法从broker-b上队列上拉取消息，导致在broker-b队列上的消息堆积，无法被消费。 解决办法：运维通过命令，在broker-b上创建对应的订阅消息，问题解决。 经验教训：集群扩容时，需要同步在集群上的topic.json、subscriptionGroup.json文件。 RocketMQ 理论基础，消费者向 Broker 发起消息拉取请求时，如果broker上并没有存在该消费组的订阅消息时，如果不允许自动创建(autoCreateSubscriptionGroup 设置为 false)，默认为true，则不会返回消息给客户端，其代码如下：问题解决后，我们团队的成员也分享了一下他在本次排查问题的处理方法：寻找出现问题的规律、推断问题、 然后验证问题。规律可以是问题本身的规律 也可以是和正常对比的差。 原文发布时间为：2019-09-08本文作者：丁威，《RocketMQ技术内幕》作者。本文来自中间件兴趣圈，了解相关信息可以关注中间件兴趣圈。
2019-09-15
优秀的个人博客,低调大师

Openstack 之 调整nova相关参数

可以是kolla部署前，也可以在kolla部署后进行配置。如果是kolla部署前，要修改/etc/kolla/config/{nova-compute.conf,nova-api.conf,nova-scheduler.conf,nova-conductor.conf,nova-consoleauth.conf,nova-novncproxy.conf}配置文件，添加以下内容： [DEFAULT] service_down_time = 120 cpu_allocation_ratio = 8.0 //可以按照比例1:8使用VCPU ram_allocation_ratio = 1.5 //可以按照比例1:8使用VCPU reserved_host_disk_mb = 2048 //host保留容量2G reserved_host_memory_mb = 2048 //host保留内存2G allow_resize_to_same_host = True remove_unused_base_images = False image_cache_manager_interval = 0 resume_guests_state_on_host_boot = True //物理主机重启后虚拟机保留上次状态 如果是部署后，需要修改/etc/kolla/{nova-compute,nova-api,nova-scheduler,nova-conductor,nova-consoleauth,nova-novncproxy}/nova.conf 修改的内容与上面一样。上面几个参数，物理主机重启后虚拟机保留上次状态在实际使用中还是比较方便，一般都需要设置，否则物理机重启后，虚拟机要重新手动启动。 本文转自yuweibing51CTO博客，原文链接：http://blog.51cto.com/yuweibing/2071364 ，如需转载请自行联系原作者
2017-11-08

资源下载

更多资源
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

时间: 2026-08-21 大小: 1MB 下载: 10次
Rocky Linux

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。

时间: 2026-08-21 大小: 1.42GB 下载: 6次
Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。

时间: 2026-08-21 大小: 9.84MB 下载: 40次
WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源，继承了IntelliJ IDEA强大的JS部分的功能。

时间: 2025-12-13 大小: 249.54MB 下载: 22次
热门标签
DeepSeek Jdk25 OpenAi HarmonyOS6 Nacos3 SpringBoot4 SpringCloud Docker Kubernetes Service Mesh Redis Gemini3 Rocky

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册