首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    Docker快速启动日常应用总结

    在“配置Docker加速器”里有配置加速的指令:    在Linux中进行配置   执行sudo su -,获取root权限,如果本身是root帐号,可跳过:  [root@node01 ~]# sudo...准备MongoDB数据存放目录,我这里是:/home/erikxu/mongo   4....httpclose #每次请求完毕后主动关闭http通道,haproxy不支持keep-alive,只能模拟这种模式的实现   #option redispatch #当serverId对应的服务器挂掉后,...  timeout client 30000ms #客户端超时   timeout server 30000ms #服务器超时   #timeout check 2000 #心跳检测超时   #timeout...http-keep-alive10s #默认持久连接超时时间   #timeout http-request 10s #默认http请求超时时间   #timeout queue 1m #默认队列超时时间

    1.8K10

    SpringBoot 中 HikariCP 的相关配置

    自 SpringBoot 2.0 起,默认的数据库连接池便是 HikariCP,在 pom 文件中引入spring-boot-starter-parent后便无需再引入 HikariCP 的依赖。...SQLException,最低可接受时间为 250ms,默认值为30000ms idleTimeout:池中连接保持空闲状态的最长时间,只有在定义的minimumIdle 小于maximumPoolSize...默认为 0 (disabled) maxLifetime:控制连接池中连接的最长时间,正在使用的连接不会被删除,只有当其关闭连接后才会被删除,当设置为 0 时表示永不删除,最小允许值为 30000ms。...默认值为 false allowPoolSuspension:控制连接池是否可以通过JMX暂停和恢复,当连接池暂停时,对 getConnection() 的调用永不超时,直到连接池恢复。...默认值为 driver default connectionInitSql:设置一个 SQL 语句,该语句将在每次创建新连接后执行,然后再将其添加到池中。

    2.8K21

    Apache Kafka 生产者配置和消费者配置中文释义

    ProducerBatch内存区域的大小,默认16kb 4.acks 指定分区中必须有多少个副本收到这条消息,才算消息发送成功,默认值1,字符串类型 5.linger.ms 指定ProducerBatch在延迟多少毫秒后再发送...接收缓冲区大小,默认32kb,-1将使用操作系统的设置 9.max.request.size 限制生产者客户端发送消息的最大值,默认1MB 10.reconnect.backoff.ms 连接失败后,...metrics日志记录级别,默认info 19.metric.reporters 类的列表,用于衡量指标,默认空list 20.max.in.flight.requests.per.connection 可以在一个...拦截器类,实现ProducerInterceptor接口,自定义拦截器 28.enable.idempotence true为开启幂等性 29.transaction.timeout.ms 事务超时时间...一次拉取请求的最大消息数,默认500条 3.max.poll.interval.ms 指定拉取消息线程最长空闲时间,默认300000ms 4.session.timeout.ms 检测消费者是否失效的超时时间

    90130

    HAProxy代理MySQL Cluster集群安装

    运行haproxy 用户 UID    gid 99                    #运行haproxy 用户组gid    #debug      #haproxy 调试级别,建议只在开启单进程的时候调试...每次请求完毕后主动关闭http通道,haproxy不支持keep-alive,只能模拟这种模式的实现          option redispatch      #当serverId对应的服务器挂掉后,...          timeout client 30000ms  #客户端超时          timeout server 30000ms  #服务器超时          #timeout...check 2000      #心跳检测超时          #timeout http-keep-alive10s  #默认持久连接超时时间          #timeout http-request...  10s  #默认http请求超时时间          #timeoutqueue          1m    #默认队列超时时间          balance roundrobin

    59710

    8.Consumerconfig详解

    一次拉取请求的最大消息数,默认500条 3.max.poll.interval.ms 指定拉取消息线程最长空闲时间,默认300000ms 4.session.timeout.ms 检测消费者是否失效的超时时间...直到满足这个配置大小,默认1b 12.fetch.max.bytes 消费者客户端一次请求从Kafka拉取消息的最大数据量,默认50MB 13.fetch.max.wait.ms 从Kafka拉取消息时,在不满足...receive.buffer.bytes Socket发送缓冲区大小,默认64kb,-1将使用操作系统的设置 18.client.id 消费者客户端的id 19.reconnect.backoff.ms 连接失败后,...设置多久之后关闭空闲连接,默认540000ms 30.request.timeout.ms 客户端将等待请求的响应的最大时间,如果在这个时间内没有收到响应,客户端将重发请求,超过重试次数将抛异常,默认30000ms...31.default.api.timeout.ms 设置消费者api超时时间,默认60000ms 32.interceptor.classes 自定义拦截器 33.exclude.internal.topics

    1.8K20

    玩转mongoDB(九):通过log4jmongo来实现分布式系统的日志统一管理

    背景  在分布式系统中,我们有多个web app,这些web app可能分别部署在不同的物理服务器上,并且有各自的日志输出。...由于这里是mongoDB的篇章,所以主观上以mongoDB来做日志数据存储;客观上,一是因为它轻便、简单,与log4j整合方便,对系统的侵入性低。...3、在pom.xml文件中,添加log4j、log4mongo-java、mongo-java-driver三个依赖。...文件中主要添加log4j对mongoDB的适配器org.log4mongo.MongoDbAppender。这里的适配器是log4mongo-java这个jar包提供。...或固定集合大小两种方式来解决: TTL索引:db.log_events.createIndex({"timestamp": 1},{expireAfterSeconds: 60*60*24*30}) #1个月后过期后删除

    60031

    【Redis】Redis 哨兵

    修改配置后,原始的master恢复了怎么办?...,对服务器压力越小,同步速度越慢;这个值越大,对服务器压力越大,同步速度越快 sentinel parallel-syncs mymaster 1 # 如果同步时间超过180000ms,就认为数据同步超时...我们演示一下这个功能 我们先退出master 我们在哨兵配置文件中设置的是,30000ms内master没有响应,哨兵则认为master已经宕机,30000ms后,哨兵1的终端有如下提示信息: 作为...并把下线的旧6379master设置为slave,后面6379上线后直接就是slave 我们启动6379 redis服务器 查看26379的提示信息,发现6379成为slave 三、哨兵工作原理 哨兵在进行主从切换过程中经历三个阶段...通知 sentinel会轮流询问master和slave的信息,然后在sentinel的朋友圈发布,其他sentinel进行订阅 3.

    38940

    motan之异步调用

    ,消费端需要配置调用超时时间,在motan-client.xml中配置: log4j system properly. server start... ④.启动客户端 等待5s后服务端控制台打印: log4j:WARN No appenders could be...注意:在server端休眠的时候,client端是阻塞着的,由于我们超时时间跟上方一致配置的是8s,所以并不会超时,导致client一致阻塞,我们试着把超时实际调为3s(比server休眠时间短):...等待5s后返回 说明:client使用监听器监听server是否执行完毕,若server实际执行业务的时间在client端配置的接口请求超时时间之内,那么client请求后会一致阻塞着,直到server...实际业务执行完成返回; 若server实际执行业务的时间大于client端配置的接口请求超时时间,那么一旦到达超时时间,直接抛出异常。

    1.2K10

    motan之异步调用

    ,假设A方法调用B方法,不同的是A方法调用B方法后,B方法很快的返回给A方法个答复(这个答复不是执行完整个B方法的答复),A方法收到答复后就执行本身,这个是异步调用,不管B方法是否耗时,整体的效率都提升...,消费端需要配置调用超时时间,在motan-client.xml中配置: 在server端休眠的时候,client端是阻塞着的,由于我们超时时间跟上方一致配置的是8s,所以并不会超时,导致client一致阻塞,我们试着把超时实际调为3s(比server休眠时间短):...等待5s后返回 说明:client使用监听器监听server是否执行完毕,若server实际执行业务的时间在client端配置的接口请求超时时间之内,那么client请求后会一致阻塞着,直到server...实际业务执行完成返回; 若server实际执行业务的时间大于client端配置的接口请求超时时间,那么一旦到达超时时间,直接抛出异常。

    80640

    如何避免承载亿级用户的服务端雪崩

    在某些场景的使用过程中,用户在客户端请求超时后会不断重试,可能导致服务端大量请求积压,出现恶性循环甚至导致服务雪崩。...为了更好地避免服务雪崩,腾讯云MongoDB建议设置服务端超时,并和客户端超时保持一致。这样在客户端出现超时后,服务端也立刻终止这些“无意义”请求的执行。...时能够主动超时和打断,因此更低版本在 qr/qw 较大,请求排队比较严重时无法及时超时退出;而且在 3.7.3 版本通过 SERVER-32638  (https://jira.mongodb.org...原生版本问题 在腾讯云MongoDB运营过程中,发现原生版本有 2 个比较大的使用痛点:一是原生 5.0 以下版本,在分片集群模式下不支持insert/update/delete 写命令的超时;二是缺乏服务端默认的...腾讯云MongoDB在原生版本的基础上,解决了 4.0 和 4.2 版本无法在 mongos 侧正确处理写命令超时的问题,并支持了服务端的默认配置,保证服务端超时后能很快退出,防止后端请求积压导致服务雪崩

    84830

    巧用 maxTimeMS 服务端超时,避免承载亿级用户的腾讯云数据库MongoDB服务雪崩

    在某些场景的使用过程中,用户在客户端请求超时后会不断重试,可能导致服务端大量请求积压,出现恶性循环甚至导致服务雪崩。...为了更好地避免服务雪崩,腾讯云MongoDB建议设置服务端超时,并和客户端超时保持一致。这样在客户端出现超时后,服务端也立刻终止这些“无意义”请求的执行。...时能够主动超时和打断,因此更低版本在 qr/qw 较大,请求排队比较严重时无法及时超时退出;而且在 3.7.3 版本通过 SERVER-32638  (https://jira.mongodb.org...原生版本问题 在腾讯云MongoDB运营过程中,发现原生版本有 2 个比较大的使用痛点:一是原生 5.0 以下版本,在分片集群模式下不支持insert/update/delete 写命令的超时;二是缺乏服务端默认的...腾讯云MongoDB在原生版本的基础上,解决了 4.0 和 4.2 版本无法在 mongos 侧正确处理写命令超时的问题,并支持了服务端的默认配置,保证服务端超时后能很快退出,防止后端请求积压导致服务雪崩

    73620

    巧用 maxTimeMS 服务端超时,避免承载亿级用户的腾讯云数据库MongoDB服务雪崩

    在某些场景的使用过程中,用户在客户端请求超时后会不断重试,可能导致服务端大量请求积压,出现恶性循环甚至导致服务雪崩。...为了更好地避免服务雪崩,腾讯云MongoDB建议设置服务端超时,并和客户端超时保持一致。这样在客户端出现超时后,服务端也立刻终止这些“无意义”请求的执行。...时能够主动超时和打断,因此更低版本在 qr/qw 较大,请求排队比较严重时无法及时超时退出;而且在 3.7.3 版本通过 SERVER-32638  (https://jira.mongodb.org...原生版本问题 在腾讯云MongoDB运营过程中,发现原生版本有 2 个比较大的使用痛点:一是原生 5.0 以下版本,在分片集群模式下不支持insert/update/delete 写命令的超时;二是缺乏服务端默认的...腾讯云MongoDB在原生版本的基础上,解决了 4.0 和 4.2 版本无法在 mongos 侧正确处理写命令超时的问题,并支持了服务端的默认配置,保证服务端超时后能很快退出,防止后端请求积压导致服务雪崩

    1.2K50

    MongoDB特定场景性能数十倍提升优化实践(记一次MongoDB核心集群雪崩故障)

    因此,结合抓包和客户端配置,可以确定当代理超过指定超时时间还没有给客户端db.isMaster()返回值,则客户端立马超时,超时后立马发起重连请求。...客户端启用6000个并发链接,超时时间500ms 通过上面的操作,可以保证所有请求超时,超时后客户端又会立马开始重新建链,再次建链后访问MongoDB还会超时,这样就模拟了反复建链断链的过程。...为了验证更高并反复建链断链在Linux-3.10内核版本是否有2.6版本同样的sy%内核态CPU消耗高的问题,因此把并发从6000提升到30000,验证结果如下: 测试结果:通过修改MongoDB内核版本故意让客户端超时反复建链断链...但是,在Linux-3.10版本中,并发到10000后,sy%负载逐步增加,并发越高sy%负载越高。...),就造成在流量峰值的时候引起连锁反应(突发流量系统负载高引起客户端快速超时,超时后快速重连,进一步引起超时,无限死循环)。

    1.2K20
    领券