Logo

  • wyait

    发布于:16 天前

    8

    springboot + shiro 权限注解、统一异常处理、请求乱码解决
    基于spring boot + mybatis + layui + shiro后台权限管理系统,新增功能:1. 新增shiro权限注解;2. 请求乱码问题解决;3. 统一异常处理。
    阅读 10000+ 评论 0 收藏 3
  • 技术小疯子

    发布于:17 天前

    5

    Walle的详细部署、项目应用以及502bad gateway错误解决
    对walle工具应用部署,和项目的配置,以及再搭建过程中解决的502错误提供办法
    阅读 5425 评论 0 收藏 3
  • 纯洁微笑

    发布于:19 天前

    17

    给大家聊一聊云收藏从 Spring Boot 1.0 升级到 2.0 所踩的坑
    给大家聊一聊云收藏从 Spring Boot 1.0 升级到 2.0 所踩的坑
    阅读 10000+ 评论 2 收藏 1
  • ExcitedBoy45

    发布于:20 天前

    70

    被黑了,SSH服务需要大整顿
    被黑经历:有一天下午,后台所有网址全部被跳转,第一反应就是服务器被黑了。首先到监测站点被篡改的脚本日志查看,检查主节点服务器上代码的完整性,发现index.php文件有被窜改的痕迹,所以导致跳转。xshell远程连接服务器,普通用户连不了,用root发现连不上密码显示错误,很明显,被黑后密码被篡改,还好其它节点做了ssh连接免密机制,连进去没多久就被踢出终端连接了,普通用户的/etc/shadow
    阅读 10000+ 评论 26 收藏 21
  • 甘兵

    发布于:22 天前

    17

    【企业实战】:阿里云高可用架构之“CDN+WAF+SLB+ECS”
    回顾历史相信有些朋友看过笔者之前写的这篇文章《如何为企业快速设计高可用的阿里云架构》,并对阿里云的一些服务和产品的选型有了初步的了解,其实这篇文章写得比较粗,只是对企业选型描述大概的框架。关于具体实过程、配置操作并没有在文章中阐述,有些博友看了也不过瘾。在这段时间中,基于广大博友的建议,笔者要和大家一起来讨论一下《阿里云高可用架构之“CDN+WAF+SLB+ECS”》如何实现,以及具体配置过程是怎
    阅读 9186 评论 18 收藏 14
  • 小柒2015

    发布于:24 天前

    7

    从构建分布式秒杀系统聊聊Disruptor高性能队列
    前言秒杀架构持续优化中,基于自身认知不足之处在所难免,也请大家指正,共同进步。文章标题来自码友<tukangzheng>的建议,希望可以把阻塞队列ArrayBlockingQueue这个队列替换成Disruptor,由于之前曾接触过这个东西,听说很不错,正好借此机会整合进来。简介LMAXDisruptor是一个高性能的线程间消息库。它源于LMAX对并发性,性能和非阻塞算法的研究,如今构
    阅读 6742 评论 1 收藏 2
  • 宋国建

    发布于:24 天前

    5

    硬盘物理故障开盘+RAID-5阵列瘫痪恢复数据过程
    服务器数据恢复故障描述服务器型号:HPP2000服务器操作系统:VMWAREESX服务器文件系统:VMFS磁盘阵列级别:RAID-5需要进行数据恢复的服务器挂载了8块硬盘组成RAID-5磁盘阵列,其中4号盘是热备盘,服务器在正常运行中两块硬盘亮×××故障灯,经用户方维护人员检测,故障硬盘应为物理故障,表现为:序列号无法读取,在SAS扩展卡上硬盘无法识别。需要对raid磁盘阵列进行数据恢复**硬盘物理
    阅读 3072 评论 2 收藏 1
  • hcymysql

    发布于:25 天前

    23

    MariaDB10.3 系统版本表 有效防止数据丢失
    系统版本表是SQL:2011标准中首次引入的功能。系统版本表存储所有更改的历史数据,而不仅仅是当前时刻有效的数据。举个例子,同一行数据一秒内被更改了10次,那么就会保存10份不同时间的版本数据。就像《源代码》电影里的平行世界理论一样,你可以退回任意时间里。从而有效保障你的数据是安全的,DBA手抖或程序BUG引起的数据丢失,在MariaDB10.3里已成为过去。
    阅读 7988 评论 5 收藏 5
  • lilugoodjob

    发布于:26 天前

    29

    MySQL查询语句中的IN 和Exists 对比分析
    最近在写SQL语句时,对选择IN 还是Exists 犹豫不决,于是把两种方法的SQL都写出来对比一下执行效率,发现IN的查询效率比Exists高了很多,于是想当然的认为IN的效率比Exists好,但本着寻根究底的原则,我想知道这个结论是否适用所有场景,以及为什么会出现这个结果。 网上查了一下相关资料,大体可以归纳为:外部表小,内部表大时,适用Exists;外部表大,内部表小时,适用IN。那我就困惑了,因为我的SQL语句里面,外表只有1W级别的数据,内表有30W级别的数据,按网上的说法应该是Exists的效率会比IN高的,但我的结果刚好相反!! “没有调查就没有发言权”!于是我开始研究IN 和Exists的实际执行过程,从实践的角度出发,在根本上去寻找原因,于是有了这篇博文分享。
    阅读 10000+ 评论 11 收藏 4
  • 品鉴初心

    发布于:27 天前

    3

    k8s原生的集群监控方案(Heapster+InfluxDB+Grafana)
    k8s原生的集群监控方案(Heapster+InfluxDB+Grafana)Heapster+InfluxDB+Grafana简介heapster是一个监控计算、存储、网络等集群资源的工具,以k8s内置的cAdvisor作为数据源收集集群信息,并汇总出有价值的性能数据(Metrics):cpu、内存、network、filesystem等,然后将这些数据输出到外部存储(backend),如Inf
    阅读 3369 评论 2 收藏 1
写文章