不怀好意的人知道了我的IP地址，有问题吗？-CSDN社区

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连接池优化、数据库配置优化、数据库连接池优化。

授权方式：开源软件界面语言：简体中文文件大小： 43.6 MB 更新时间： 2020-07-31 资源类型：国产软件推荐等级： ★★★☆☆ 平台环境： JAVA 作者主页：点击查看演示地址：点击查看详细介绍 – [ spring-boot-seckill分布式秒杀系统 v1.0 ] spring-boot-seckill分布式秒杀系统是一个用SpringBoot开发的从0到1构建的分布式秒杀系统，项目案例基本成型，逐步完善中。 spring-boot-seckill分布式秒杀系统安装使用开发环境： 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、本测试案例单纯为了学习，某些案例并不适用于生产环境，大家根据所需自行调整。 spring-boot-seckill分布式秒杀系统架构层级 1、一般商家在做活动的时候，经常会遇到各种不怀好意的DDOS攻击(利用无辜的吃瓜群众夺取资源)，导致真正的我们无法获得服务！所以说高防IP还是很有必要的。 2、搞活动就意味着人多，接入SLB，对多台云服务器进行流量分发，可以通过流量分发扩展应用系统对外的服务能力，通过消除单点故障提升应用系统的可用性。 3、基于SLB价格以及灵活性考虑后面我们接入Nginx做限流分发，来保障后端服务的正常运行。 4、后端秒杀业务逻辑，基于Redis 或者 Zookeeper 分布式锁，Kafka 或者 Redis 做消息队列，DRDS数据库中间件实现数据的读写分离。 spring-boot-seckill分布式秒杀系统优化思路 1、分流、分流、分流，重要的事情说三遍，再牛逼的机器也抵挡不住高级别的并发。 2、限流、限流、限流，毕竟秒杀商品有限，防刷的前提下没有绝对的公平，根据每个服务的负载能力，设定流量极限。 3、缓存、缓存、缓存、尽量不要让大量请求穿透到DB层，活动开始前商品信息可以推送至分布式缓存。 4、异步、异步、异步，分析并识别出可以异步处理的逻辑，比如日志，缩短系统响应时间。 5、主备、主备、主备，如果有条件做好主备容灾方案也是非常有必要的(参考某年锤子的活动被攻击)。 6、最后，为了支撑更高的并发，追求更好的性能，可以对服务器的部署模型进行优化，部分请求走正常的秒杀流程，部分请求直接返回秒杀失败，缺点是开发部署时需要维护两套逻辑。 spring-boot-seckill分布式秒杀系统分层优化 1、前端优化：活动开始前生成静态商品页面推送缓存和CDN，静态文件(JS/CSS)请求推送至文件服务器和CDN。 2、网络优化：如果是全国用户，最好是BGP多线机房，减少网络延迟。 3、应用服务优化：Nginx最佳配置、Tomcat连接池优化、数据库配置优化、数据库连接池优化。 spring-boot-seckill分布式秒杀系统截图相关阅读同类推荐：站长常用源码

2、安全受到威胁：IP地址是可以直接反映所在的城市，通过一定的技术侦察，还能得到更加详细的地址，继而可能会为自己的人身安全带来威胁。1、被恶意攻击：如果我们的IP地址泄露，被不怀好意的他人知道，那么他可以利用一些手段对我们的电脑发起恶意攻击，造成损失。第二，所有的网站密码尽量使用不同的密码，且最好使用字母+数字+标点符号的形式，比如Abc127356749!第三，非必要不使用个性化推送，用过一段时间后就会发现，你刷到的内容都是你想看的，因为它会根据喜好进行推送。

从去年开始，各大互联网平台陆续显示用户 IP 属地，而用户方则无法选择开启或关闭这一功能。最先被发现的，是不少认证为“本地资讯博主”和“海外资讯博主”的账号，IP 属地与资料地址并不吻合。一些人支持平台强制在前台显示用户 IP 属地，他们认为有人会因此收敛，至少无法假装在某地，假冒他人也多了一个辨别要素，在“伪现场”发生的新闻也会不攻自破；也有不少质疑，认为自己现在就相当于在大街上裸奔，个人隐私将会被继续蚕食。