部署在AWS-EC2上的Java程序无法连接AWS-RDS MySQL 数据库的问题解决

问题

我在EC2实例中放了个Java程序。当我执行 java -jar app.jar 命令时,SpringBoot应用程序能正常启动,但连接MySQL RDS数据库时却失败了。

已经打开了应用程序正在运行的端口(8090)和MySql端口(3306),用于入站和出站流量:

错误日志

解决

检查EC2实例和RDS实例的安全组(SG)配置。

可以通过EC2仪表板/ RDS仪表板->单击实例并查看“安全组”描述来进行检查,也可以单击“设置”图标(“显示/隐藏”列)并勾选“安全组”。

在RDS的SG配置中:确保已启用从EC2实例的SG到端口3306的访问。可以通过将EC2实例的SG ID作为“自定义IP”值放入配置的“源”字段中来进行此操作。有关更多详细信息,参考下面。

使用mysql命令行测试EC2实例和RDS之间的连接。

参考

VPC IntroductionSecurity in your VPCScenarios for Accessing a DB Instance in a VPC

0

mysql大数据量分页查询时的优化方法

mysql的limit分页查询,会随着偏移量的增大,效率会急剧下降。

查询device表,偏移量分别是10,100,1000,10000,然后测试查询时间。

如果直接把offset设置为40W,足足需要三秒多。

那么,有什么优化方法呢?

利用表的覆盖索引来加速分页查询优化

查询的语句中,如果只包含了索引列,那么查询就会非常快,因为利用覆盖索引查询有算法优化,并且数据就在索引上,不需要再查找相关数据地址了,而且mysql中也有索引缓存。

id字段是主键,索引就是主键索引。我们可以把语句改成这样:

可以看到速度提升了100多倍。

那其实大多数场景,我们不光是只查询id的,那如果要 select * 该怎么办呢?

一种是 >= 的写法

另一种是 join 写法

这两种写法其实原理一样,只要掌握了这些mysql大数据量分页查询时的优化方法,就再也不怕客户嫌查询慢了。

0

谷歌的短网址服务被Firebase动态链接取代

谷歌短网址服务(Google URL Shortener)现已停止支持。自2018年3月30日开始谷歌开始逐渐关闭goo.gl URL短网址服务。在2018年4月13日之后只允许现有用户继续使用短链接生成服务,另外还能查看用户的分析数据以及以CSV的格式下载短链接信息。而在2019年3月30日,goo.gl控制台将正式关闭。

谷歌短网址服务goo.gl于2009年12月14日上线,距离服务关闭有9年时间。现有的goo.gl链接仍然可以使用,但新的链接已经无法创建。谷歌建议,开发者可以转向旗下的Firebase动态链接,普通用户就只能转向别的短网址服务了。

在该服务关闭之后将会被全新的Firebase动态链接所取代,它是一种“智能网址”,除了网页以外它还可以方便地将用户“转到 iOS 或 Android 应用中的任意位置”,显然在 Google 眼中它会比原来的 goo.gl 更加好用。

0

小白想问百度短网址安全吗?

百度短网址安全吗?

是安全的。

百度短网址服务包括其它正规平台的短网址服务其实都是安全的,因为它只是给目标url和对应的短url生成一个映射,这个映射可以是通过算法实现,也可以是通过存储服务实现,它并不会跟踪网站或者发动什么攻击。而且现在百度短网址服务已经开始收费了,那更会保证安全性了,所以可以放心使用。

0

短网址是什么?它的原理是什么?

短网址解释

短网址的另外一个名字叫“短链接”,其实就是把一个长连接缩短得到的比较短的链接。
自从微博出现之后,这种网址缩短服务就开始流行了,原因其实很简单,微博是有140字数限制的,人们需要将内容通过精简的文字表达出来,如果再出现一个链接,那么就会占用比较大的篇幅,所以需要将这个链接尽量缩短,这样既美观,又节省了文字篇幅,两全其美。

短网址原理

短网址的原理其实很简单,通过某种算法将长网址压缩(可以理解为哈希算法),然后将其保存到数据库中跟原网址做一个映射,用户在请求时,后台服务器会先查询这个映射,然后301或者302跳转到原有的网址。

短网址优点

节省网址长度,便于社交化传播
方便后台统计用户点击和区域分布
规避关键词和域名屏蔽
隐藏真实地址,还可以通过短网址加密来做付费推广链接

常见短网址平台

1.微博短网址
2.百度短网址

0

在1024程序员节给这个群体做个特征总结

自己作为程序员有些年头了,合作的程序员也是形形色色,回顾总结,发现不管程序员性格是外向的还是内向的,是话痨还是闷棍,他们都有一些共同特征,现在正好是1024程序员节,就随便总结一下,图个乐。

别人写的代码都是垃圾,自己写的才是最好的

这个现象不用多阐述,如果你是程序员,应该深有感悟。如果你还觉得感悟不深刻,你就看看你公司代码里面是不是有类似于多个版本的诸如thread pool啊,object pool啊。

喜欢写一些“高深的,别人看不懂的”代码

最高层次就是:一行代码,n个功能,别人都不懂,只有作者他自己懂。随后,这个便成了炫耀的资本,到处说:“来,你过来看,知道这行代码是干什么的吗?恩,就知道你不知道,哈哈。”倒霉的是下次去维护这种代码的人。

认为越接近机器码的语言,就越是高级的有技术含量的编程语言

在他们眼里,直接写01010110才是最高技术,实在记不住,才用汇编。汇编还记不住,那才就用c/cpp。java/C#一点技术含量也没有。

程序结构大于一切,客户的NC需求可以不予理会

有些程序员,真是极其注重程序的结构设计,当然这个没有错,我也相当认可,但是你知道的,客户那需求可是一直要改啊改的,而且有一些是出乎当初我们预料的改动,但客户才不管呢,反正按时按需完成就是了。但是,碰到有些程序员,好说歹说,他死活不肯改,说改了会影响程序结构啊,设计就很难看之类的。说实话,我也很认同,确实对结构有影响,但是我们得搞清楚谁是衣食父母啊,是客户啊,不是结构!所以,我很想对这类程序员说:有本事你看着程序结构就饱了,别吃饭啊。

对程序性能有时候很神经质

记得有一次,我们需要写一个桌面应用程序,有个程序员和我讨论了很长时间到底应该用系统lock还是自己写一个基于计数器的lock(这里我不得不说,那些程序员都是很好的程序员,理论知识很丰富深刻,以上海西南某高校居多)。我承认,基于计数器的lock确实比较高效,因为不用使程序陷入内核态。但是,对于一个本身就是慢速的用户桌面应用,有必要自己实现一个高效lock吗?自己实现,增加了开发测试成本,而且还增加了很多bug几率。如果把这些时间花在改进用户UI上,那不是远比为了快那么几十毫秒来的更有价值吗?

总结

程序员一直给人印象是:性格怪异,智商高,粘着椅子,敲着电脑。我要说的是,这个都是误解。其实现实中的程序员大多数是很开朗的,和其他人没什么两样。但程序员有时候工作是非常辛苦的,可以为了修一个bug而通宵达旦,对生活和健康影响都很大。所以,我祝每个程序员都幸福健康。。。

0

对于帆软软件售后的一些吐槽

不好的使用体验

既然是吐槽,那肯定是帆软的一些东西让我很不爽,那就是售后的技术支持(另外软件里有的代码也写的很垃圾,不过代码质量不是本文的重点)。

刚开始我们公司技术选型选了帆软报表,一是因为它的市场占有量是第一,二是因为承诺的技术支持。现在使用中,我们需要在报表中添加一个自动生成目录(附带目录项页码)的功能,从市场需求角度看,这应该是一个基础的需求,再从开发的角度看,这应该也不是一个复杂的问题。可是帆软报表,就是不支持。(而且他们的代码也不是开源的,不然可以自己修改源码来曲线救国。)

不支持那就得想办法解决,首先我把他们的帮助文档翻了个遍,还是没找到解决问题的方法。他们官方论坛也看了下,发现有个人和我有类似的需求。本来很激动,以为问题下面会有解决方法。然并卵,下面没有答案。

于是就去找他们的客服,和他们售后客服沟通真是费劲。

首先要去他们的企业QQ,然后转人工QQ,转了人工,我把我的需求和他说一遍,说不清楚的地方也截图了,可客服的反应那个迟钝,我每问一个问题,回答都要很长时间。只要问的问题和他们文档里有沾边的,就直接丢个链接,然后就没下文了。问的问题他们文档里没有,那就牛逼了,可能要半天甚至一天才会给你答复,关键答复的内容也解决不了问题。要么直接说这个没办法解决,要么就模棱两可的丢个相似功能的链接给你。

得亏我时间不是太急,这中间断断续续找了他们大概有三次,每次和第一个人沟通完了。第二次又是随机客服,又要重复第一次的步骤,走一遍那个折磨人的流程。所以,从那之后,不管有没有问题,我都没有再找他们客服了。

因为我知道,有问题问了也没用,要么就丢个链接,要么就直接回复没解决方法,要么就顾左右而言它,永远说不到点子上。响应还贼慢。

这和刚开始销售软件的时候,完全就是一个天一个地。销售的时候那叫一个勤快,专人微信电话沟通,问个问题都是秒回。给的承诺也是放心使用,有强大的技术支持。-_-||

沟通截图

下面附上我和他们客服沟通的部分截图,留意一下截图里的时间,短短几个对话,从早上九点多,持续到下午两点,最后干脆就直接没下文了。

总结

这些感想只是我个人使用帆软软件的一些感受,不代表其它人,如果不巧别人甚至多数人都有这些不好的体验或者感觉,那我觉得帆软应该反思一下了。

  1. 帆软软件的质量并不像它的市场份额和售价那样,达到了行业第一的位置。这个质量包括,代码架构、技术能力和服务水平。
  2. 售后的客服可能一点技术都不懂,每次只要有个他们话术里没有的问题,可能都要屁颠屁颠跑到工程师那边一个个问。(脑补一下)
  3. 软件技术架构不合理,导致积重难返,很多看似很简单的问题,都没法轻易改。这个做过开发的都知道。他们的工程师可能也很郁闷,怎么客户问的问题都是自己解决不了的问题。
  4. 给我的感觉帆软是一个重营销,轻技术的公司。

总之很郁闷,又没处发泄,所以我要记录一下,本文地址,http://791202.com/2020/10/25/java/1472/,软件售价那么贵,服务质量却没有跟上。

0

遍历javascript数组方法总结

Javascript 遍历数组(循环数组)的方式有多种,可以使用传统的 for 循环,也可以使用升级版的 for in 循环,还可以使用 Array 类型的 forEach() 方法;如果希望遍历对象的键名,还可以使用 keys() 方法。

使用 for 和 for in遍历数组

for 和 for/in 语句都可以迭代数组。for 语句需要配合 length 属性和数组下标来实现,执行效率没有 for/in 语句高。另外,for/in 语句会跳过空元素。

对于超长数组来说,建议使用 for/in 语句进行迭代。

下面示例使用 for 语句迭代数组,过滤出所有数字元素。

下面代码使用 for/in 语句迭代示例 1 中的数组 a。在 for/in 循环结构中,变量 i 表示数组的下标,而 a[i] 为可以读取指定下标的元素值。

通过计时器可以看到,for/in 语句迭代数组,仅循环了 7 次,而 for 语句循环了 42 次。

使用 forEach 遍历数组

Array 类型为每个数组定义了 forEach() 原型方法,使用该方法可以为数组执行迭代操作。具体说明如下:

参数说明如下:

  • array:一个数组对象。
  • callbackfn:必需参数,最多可以接收三个参数的函数。forEach 将为数组中的每个元素调用 callbackfn 函数一次。
  • thisArg:可选参数,callbackfn 函数中的 this 可引用的对象。如果省略 thisArg,则 this 的值为 undefined。

对于数组中出现的每个元素,forEach 方法都会调用 callbackfn 函数一次,采用升序索引顺序,但不会为数组中空元素调用回调函数。

除了数组对象之外,forEach 方法还可以用于有 length 属性且具有已按数字编制索引的属性名的任何对象,如关联数组对象、Arguments 等。

回调函数语法如下:

最多可以使用三个参数来声明回调函数。回调函数的参数说明如下。

forEach 方法不直接修改原始数组,但回调函数可能会修改它。在 forEach 方法启动后修改数组对象所获得的结果如表所示。

forEach 方法启动后的条件元素是否传递给回调函数
在数组的原始长度之外添加元素
添加元素以填充数组中缺少的元素是,如果该索引尚未传递给回调函数
元素已更改是,如果该元素尚未传递给回调函数
从数组中删除元素否,除非该元素已传递给回调函数
回调函数修改数组的影响

下面示例使用 forEach 迭代数组 a,然后把每个元素的值和下标索引输出显示,代码如下:

演示结果如下:

下面示例使用 forEach 迭代数组 a,然后计算数组元素的和并输出。

下面示例演示如何使用 forEach() 方法的第二个参数,该参数为回调函数的 this 传递对象。当迭代数组过程中,先读取数组元素的值,然后改写它的值。

使用 keys 遍历对象键名

keys() 是 Object 的静态函数,专门用来遍历对象获取键名。Object.keys() 函数的参数是一个对象,返回一个数组,元素是该对象所以本地属性名。如果使用该函数迭代数组,可以汇集数组的所有元素下标值。

下面代码直观的比较了 keys 迭代对象和数组的不同。

keys 功能比较专一,应用范围比较窄,但是执行效率比较高。

除了获取键名集合外,使用 keys 还可以间接统计对象的长度。

Object 类型没有定义 length 原型属性,可以利用 keys 方法获取对象的长度。

Object 还有一个类似的静态函数:getOwnPropertyNames(),与 keys 用法相同,参数都是对象,返回值都是一个数组,数组元素都是属性名。不同点:keys 仅能迭代本地、可枚举的属性,getOwnPropertyNames 可以迭代所有本地属性。

数组的 length 是不可枚举的属性,所以仅能在 Object.getOwnPropertyNames 返回结果中看到。因此,要快速迭代数组,可以使用 keys 方法。

0