秒杀系统时间配置、Nginx查看服务器系统时间

时间配置

在秒杀活动中,页面往往需要显示秒杀倒计时。倒计时未结束时,按钮无法点击。如此,就会涉及到倒计时时钟的统一问题。倒计时的时钟绝对不能依赖于客户端,因为当用户的设备时钟不准确或用户处于非当前时钟时,那么倒计时就会出错。所以,倒计时的时间需要服务端统一返回,客户端根据服务端的时间进行倒计时数秒,并根据服务端的状态控制按钮。对于服务端如何提供统一的时间,有不同的方案。讲究点的可以提供统一的时间接口,这个时间是绝对准确的,不会依赖于服务器主机。当然,不讲究的可以使用下面这种方式,直接在返回秒杀品详情数据的时候返回时间和状态。在很多组织中,对于分布式的服务器都会进行统一的时间管理,不允许出现服务器之间的时钟差异。

ECS阿里云

一般公司运维会同步、校准各服务器时间,如果不可靠可以找其他替代方案,阿里云有个基于nginx的时间接口,支持百万级QPS(可能是centos默认做了NTP同步,直接nginx配置获取本地时间即可)。

阿里云提供了内网和公网NTP服务器,用于同步各网络中ECS实例的本地时间。内网和公网NTP服务器NTP是用于同步网络中计算机时间的协议,全称为网络时间协议(Network Time Protocol)。时区和时间一致性对于云服务器ECS非常重要,有时会直接影响到任务执行的结果。例如,您在更新数据库或者分析日志时,时间顺序对结果有很大影响。为避免在ECS实例上运行业务时出现逻辑混乱和网络请求错误等问题,您需要统一相关ECS实例的时区设置。另外,您还可以通过NTP服务同步各网络中ECS实例的本地时间。云服务器ECS为您提供了高精度的时间参考NTP服务器,其中ntp.cloud.aliyuncs.com服务器提供分布式的一级时钟源,适用于金融、通讯、科研和天文等以时间精度核心的生产行业。

Chrony为阿里云官方和社区推荐配置的时钟同步服务,相较于NTP有更高的时钟稳定性与更小的时间误差。当前阿里云ECS实例中,CentOS 7及以上镜像版本已默认配置Chrony服务,您无需额外配置即可正常使用。

配置

通过Nginx配置文件添加一个location,返回服务器的时间。例如:

location /time {
    default_type text/plain;
    return 200 "$time_local\n";
}

通过Nginx模块ngx_http_lua_module,使用lua脚本获取服务器的时间。例如:

location /time {
    default_type text/plain;
    content_by_lua '
        local time = os.date("%Y-%m-%d %H:%M:%S")
        ngx.say(time)
    ';
}

通过Linux命令date查看系统时间。例如:

date
  • Nginx单机百万QPS环境搭建需要注意以下几点:
    • 关闭多余的服务和进程,释放内存和CPU资源。
    • 调整Linux内核参数,优化网络连接和文件描述符等。
    • 调整Nginx配置参数,优化worker进程数、连接数、缓冲区大小等。
    • 使用wrk或ab等工具进行压力测试和性能分析。

性能:

简单查询,nginx调整后应该可以达到百万qps

Nginx单机百万QPS

  • nginx单机百万qps的硬件配置没有一个固定的标准,因为不同的应用场景和请求类型会影响服务器的性能和资源消耗。
  • 一般来说,要达到nginx单机百万qps的水平,需要具备以下条件:
    • 服务器的CPU核数足够多,至少16核以上。
    • 服务器的内存足够大,至少64G以上。
    • 服务器的网络带宽足够高,至少10Gbps以上。
    • 服务器的磁盘性能足够好,最好使用SSD或者RAID。
  • 另外,除了硬件配置之外,还需要对Linux内核参数和Nginx配置参数进行优化调整,以提高网络连接和文件描述符等资源的利用率。

参考

ECS本地时间

秒杀系统设计

  • 1
    点赞
  • 7
    收藏
    觉得还不错? 一键收藏
  • 3
    评论
spring-boot-seckill分布式秒杀系统是一个用SpringBoot开发的从0到1构建的分布式秒杀系统,项目案例基本成型,逐步完善中。 开发环境: JDK1.8、Maven、Mysql、IntelliJ IDEA、SpringBoot1.5.10、zookeeper3.4.6、kafka_2.11、redis-2.8.4、curator-2.10.0 启动说明: 1、启动前 请配置application.properties中相关redis、zk以及kafka相关地址,建议在Linux下安装使用。 2、数据库脚本位于 src/main/resource/sql 下面,启动前请自行导入。 3、配置完成,运行Application中的main方法,访问 http://localhost:8080/seckill/swagger-ui.html 进行API测试。 4、秒杀商品页:http://localhost:8080/seckill/index.shtml ,部分功能待完成。 5、本测试案例单纯为了学习,某些案例并不适用于生产环境,大家根据所需自行调整。 秒杀架构: 架构层级 1、一般商家在做活动的时候,经常会遇到各种不怀好意的DDOS攻击(利用无辜的吃瓜群众夺取资源),导致真正的我们无法获得服务!所以说高防IP还是很有必要的。 2、搞活动就意味着人多,接入SLB,对多台云服务器进行流量分发,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 3、基于SLB价格以及灵活性考虑后面我们接入Nginx做限流分发,来保障后端服务的正常运行。 4、后端秒杀业务逻辑,基于Redis 或者 Zookeeper 分布式锁,Kafka 或者 Redis 做消息队列,DRDS数据库中间件实现数据的读写分离。 优化思路 1、分流、分流、分流,重要的事情说三遍,再牛逼的机器也抵挡不住高级别的并发。 2、限流、限流、限流,毕竟秒杀商品有限,防刷的前提下没有绝对的公平,根据每个服务的负载能力,设定流量极限。 3、缓存、缓存、缓存、尽量不要让大量请求穿透到DB层,活动开始前商品信息可以推送至分布式缓存。 4、异步、异步、异步,分析并识别出可以异步处理的逻辑,比如日志,缩短系统响应时间。 5、主备、主备、主备,如果有条件做好主备容灾方案也是非常有必要的(参考某年锤子的活动被攻击)。 6、最后,为了支撑更高的并发,追求更好的性能,可以对服务器的部署模型进行优化,部分请求走正常的秒杀流程,部分请求直接返回秒杀失败,缺点是开发部署时需要维护两套逻辑。 分层优化 1、前端优化:活动开始前生成静态商品页面推送缓存和CDN,静态文件(JS/CSS)请求推送至文件服务器和CDN。 2、网络优化:如果是全国用户,最好是BGP多线机房,减少网络延迟。 3、应用服务优化:Nginx最佳配置、Tomcat连接池优化、数据库配置优化、数据库连接池优化。
spring-boot-seckill分布式秒杀系统是一个用SpringBoot开发的从0到1构建的分布式秒杀系统,项目案例基本成型,逐步完善中。 开发环境: JDK1.8、Maven、Mysql、IntelliJ IDEA、SpringBoot1.5.10、zookeeper3.4.6、kafka_2.11、redis-2.8.4、curator-2.10.0 启动说明: 1、启动前 请配置application.properties中相关redis、zk以及kafka相关地址,建议在Linux下安装使用。 2、数据库脚本位于 src/main/resource/sql 下面,启动前请自行导入。 3、配置完成,运行Application中的main方法,访问 http://localhost:8080/seckill/swagger-ui.html 进行API测试。 4、秒杀商品页:http://localhost:8080/seckill/index.shtml ,部分功能待完成。 5、本测试案例单纯为了学习,某些案例并不适用于生产环境,大家根据所需自行调整。 秒杀架构: 架构层级 1、一般商家在做活动的时候,经常会遇到各种不怀好意的DDOS攻击(利用无辜的吃瓜群众夺取资源),导致真正的我们无法获得服务!所以说高防IP还是很有必要的。 2、搞活动就意味着人多,接入SLB,对多台云服务器进行流量分发,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 3、基于SLB价格以及灵活性考虑后面我们接入Nginx做限流分发,来保障后端服务的正常运行。 4、后端秒杀业务逻辑,基于Redis 或者 Zookeeper 分布式锁,Kafka 或者 Redis 做消息队列,DRDS数据库中间件实现数据的读写分离。 优化思路 1、分流、分流、分流,重要的事情说三遍,再牛逼的机器也抵挡不住高级别的并发。 2、限流、限流、限流,毕竟秒杀商品有限,防刷的前提下没有绝对的公平,根据每个服务的负载能力,设定流量极限。 3、缓存、缓存、缓存、尽量不要让大量请求穿透到DB层,活动开始前商品信息可以推送至分布式缓存。 4、异步、异步、异步,分析并识别出可以异步处理的逻辑,比如日志,缩短系统响应时间。 5、主备、主备、主备,如果有条件做好主备容灾方案也是非常有必要的(参考某年锤子的活动被攻击)。 6、最后,为了支撑更高的并发,追求更好的性能,可以对服务器的部署模型进行优化,部分请求走正常的秒杀流程,部分请求直接返回秒杀失败,缺点是开发部署时需要维护两套逻辑。 分层优化 1、前端优化:活动开始前生成静态商品页面推送缓存和CDN,静态文件(JS/CSS)请求推送至文件服务器和CDN。 2、网络优化:如果是全国用户,最好是BGP多线机房,减少网络延迟。 3、应用服务优化:Nginx最佳配置、Tomcat连接池优化、数据库配置优化、数据库连接池优化。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值