关于EDM邮件推广

这几天在处理公司EDM邮件推广的问题,EDM推广也是公司流量的一部分流量来源。由于自己也是入门,故收集整理了一些关键词(持续更新)。

独立ip 共享ip:

  • ip信誉度(reputation):共享ip导致信誉度低
  • ESP单个ip的配额限制:共享ip导致超出配额

定制信头

  • 自定义sender address:ESP的发送域名配额,共用的sender address导致超出域名配额;而且会显示“由XXXX代发”字样。不同的sender address和from address会导致垃圾邮件评分偏高

身份验证机制

  • SPF 发送方政策框架:用于登记某个域名拥有的用来外发邮件的所有IP地址。向收信者表明,该发信服务器经过该域名认可,主要针对发信人伪造域名的垃圾邮件。
  • DKIM 域名秘钥识别邮件:私钥放在发信服务器中,发信时生成数字签名放在邮件头中;公钥放在DNS中。收件服务器收到邮件后,会将邮件头中的数字签名和DNS中获取的公钥进行比对,判断发信者的域名是否合法。
  • DMARC Domain-based Message Authentication, Reporting and Conformance,是构建与SPF和DKIM技术上的解决方案,主要针对的是钓鱼邮件。DMARC 的核心思想是邮件的发送方通过特定方式 (DNS) 公开标明自己会用到的发件服务器 (SPF)、并对发出的邮件内容进行签名 (DKIM),而邮件的接收方则检查收到的邮件是否来自发送方授权过的服务器、并且核对签名是否有效。对于未能通过前述检查项目的邮件,接收方则按照发送方指定的策略进行处理【比如直接投入垃圾箱或者拒收】,从而有效避免伪造的钓鱼邮件进入用户的收件箱。

2016-01-22更新

最近一周陆续测试了几家邮件服务商:Mailgun、Rushmail、Submail、Sendcloud、Amazon SES。

  • 大名鼎鼎的Mailgun,公司一直在用。但是企鹅邮箱的到达率有问题,所以对国内地址的发送就忽略mailgun了。
  • Rushmail,效果最好的。邮件发送时会使用多个smtp服务器进行发送,到达率高。最后没采用,因为最贵。
  • Submail,效果一般。邮件模板需要审核,适合发送触发类邮件。推广邮件就太麻烦,每次都要上传模板审核。基本上邮件都会直接进垃圾邮件。测试发型了50多封,且收件人都是我自己注册的邮箱,被Submail封号。忽略
  • Sendcloud,跟Submail差不多,邮件直接进垃圾邮件。mail-tester评分较低,主要是ip被拉黑。
  • Amazon SES,这几家里面最便宜的,发信效果暂时来看都不错,直接送达收件箱。较严重的问题就是没有国内服务器,你懂的,最后通过技术手段解决。正在使用中

关于垃圾邮件测试,推荐mail-tester。

垃圾邮件检测结果 by mail tester.com

commons-beanutils 版本问题

最近在整理公司已有项目,其中一个项目在请求solr系统的时候出现如下错误:

ERROR [ PropertyUtils ] - Method invocation failed.
java.lang.IllegalArgumentException: argument type mismatch
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_75]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[na:1.7.0_75]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_75]
	at java.lang.reflect.Method.invoke(Method.java:606) ~[na:1.7.0_75]
	at org.apache.commons.beanutils.PropertyUtilsBean.invokeMethod(PropertyUtilsBean.java:1773) [commons-beanutils-1.7.0.jar:1.6]
	at org.apache.commons.beanutils.PropertyUtilsBean.setSimpleProperty(PropertyUtilsBean.java:1759) [commons-beanutils-1.7.0.jar:1.6]
	at org.apache.commons.beanutils.PropertyUtilsBean.setNestedProperty(PropertyUtilsBean.java:1648) [commons-beanutils-1.7.0.jar:1.6]
	at org.apache.commons.beanutils.PropertyUtilsBean.setProperty(PropertyUtilsBean.java:1677) [commons-beanutils-1.7.0.jar:1.6]
	at org.apache.commons.beanutils.BeanUtilsBean.setProperty(BeanUtilsBean.java:1022) [commons-beanutils-1.7.0.jar:1.6]
	at org.apache.commons.beanutils.BeanUtilsBean.populate(BeanUtilsBean.java:811) [commons-beanutils-1.7.0.jar:1.6]
	at org.apache.commons.beanutils.BeanUtils.populate(BeanUtils.java:298) [commons-beanutils-1.7.0.jar:1.6]

调整log级别至trace之后发现,solor返回的是ArrayList,而该方法接受的参数为String数组。最后发现是commons-beanutils的版本较低导致的,下面是1.8.0的release notes。

Conversion
----------
The converter implementations have been significantly improved in this release:

1) Arrays: A new "generic" ArrayConverter has been introduced which delegates
           the individual component conversion to an appropriate Converter for
           the component type.
2) Numbers: All numeric Converters now handle conversion between numeric types
           and have improved conversion facilities to and from Strings
           based on formats and/or a specified Locale.
3) Dates: Improvements to the existing SQL Date, Time and Timestamp converters
          now handle conversion between Date/Calendar types and have improved
          conversion facilities to and from Strings based on formats and/or
          a specified Locale. New java.util.Date and Calendar converter
          implementations have been added.

 

一幅图

architect

 

  • 负载均衡
  • session服务器
  • 缓存
  • DFS
  • DDS
  • DCS
  • CDN
  • NoSQL
  • 数据库优化

 

Posted in 学习

Tags:

Permalink 5 Comments

使用Nginx实现负载均衡

关于负载均衡,实际上一直有没有用过。但是公司一直有在用,只是有专门的部门去做配置,开发人员基本接触不到。接触到也没什么意义,因为是F5的硬件负载均衡。而且这种硬件价格高,估计大公司用的都少。

硬件上的接触不到,那就看下软件的吧。比较有名的就是用Nginx实现负载均衡,据说国内很多大型的互联网公司都在用。

Nginx

关于Nginx,网上的介绍也很多。大家可以看官网(英文)和Wikipedia的介绍,下面是从Wiki上截取的:

Nginx(发音同engine x)是一款由俄罗斯程序员Igor Sysoev所开发轻量级的网页服务器、–服务器以及电子邮件(IMAP/POP3)–服务器。起初是供俄国大型的门户网站及搜索引擎Rambler(俄语:Рамблер)使用。此软件BSD-like协议下发行,可以在UNIX、GNU/Linux、BSD、Mac OS X、Solaris,以及Microsoft Windows等操作系统中运行。

安装启动很简单,Linux(Ubuntu为例):

apt-get install nginx

nginx -s signal

nginx -s stop

Windows:

http://nginx.org/download/nginx-1.9.2.zip

start nginx.exe

nginx.exe -s stop

回到负载均衡上,Nginx目前支持三种方式:

round-robin — requests to the application servers are distributed in a round-robin fashion, (请求在几个节点间是依次循环分发)
least-connected — next request is assigned to the server with the least number of active connections, (请求被分发到持有最少连接的节点)
ip-hash — a hash-function is used to determine what server should be selected for the next request (based on the client’s IP address). (对请求的IP做哈希运算,然后判断分发到哪个节点)

1. 默认的配置很简单,只需要在nginx.conf中的http部分添加如下配置:

http {
    upstream demo {
        server localhost:8080;
        server localhost:8081;
        server localhost:8082;
    }

    server {
        listen 80;
        server_name localhost;
        location / {
            proxy_pass http://demo;
        }
    }
}

比如,我本地demo集群下有三个服务器作为节点,对应的端口分别是8080、8081和8082。Nginx监听localhost上的80端口,对所有“/”下的请求转发demo集群下的节点上。默认的方式是round-robin。

Nginx可以为HTTP, HTTPS, FastCGI, uwsgi, SCGI, and memcached提供负载均衡。

如果是为HTTPS提供负载均衡,只需要切换到HTTPS协议和相应的端口。memcached是一个开源的缓存系统,通过Nginx的负载均衡,可以搭建分布式的缓存系统。这是只需要把proxy_pass换成memcached_pass并指向对应的集群或者服务器。

2. Least connected负载均衡

round-robin有个缺点,比如有些请求完成的时间比较长,循环分配的方式会导致某个或某些节点的负载比较大,达不到均衡的目的。

Least connected就解决了这种问题,nginx会根据节点的活动连接数把请求分发到活动连接数少的节点上。

upstream demo {
        least_conn;
        server localhost:8080;
        server localhost:8081;
        server localhost:8082;
    }

这里不得不提的就是以上两种方式下,同一个会话的不同请求可能会被分发到不同的节点上,这样就会出现session的持久化问题。

3. ip-hash负载均衡

客户端的ip会作为哈希key去判断请求应该被分发的哪个节点上,这就意味着同一会话(ip不变)的不同请求都是被分发到同一个节点上。

upstream demo {
        ip_hash;
        server localhost:8080;
        server localhost:8081;
        server localhost:8082;
    }

4. 加权的负载均衡

上面的三种方式里,我们假设的是所有的节点性能相同,都会被同等的对待。如果服务器的性能不均,使用以上三种方式便达不到均衡的目的。这时我们可以在配置集群的时候为不同的服务器加上权重,以达到均衡的目的。

加权的方式,可以和以上三种结合使用。

upstream demo {
        server localhost:8080 weight=3;
        server localhost:8081;
        server localhost:8082;
    }

weight=3作用是保证每5个请求中的3条会被分发到8080端口的节点上。

健康检查

Nginx中提供了通信内(被动)的检查,如果来自某个节点响应失败,Nginx便会把该检点标识成failed,并在一段时间内避免把请求分发到该节点。

max_fails检查表示该节点响应连续失败(非超时)的次数,默认情况下值是1。0表示不会对该节点做健康检查。fail_timeout表示该节点被认定fail并保持多久,一旦时间超过,Nginx会试着将请求分发到该节点。如果成功,改节点便会被标识成有效。

upstream demo {
        server localhost:8080;
        server localhost:8081 fails_timeout=5s;
        server localhost:8082 max_fail=3;
    }

更多

上面只是Nginx负载均衡中设置的冰山一角,比如proxy_next_upstream, backup, down, and keepalive。