技術めも

持続的接続をredisで行う場合、

接続は１つでよいと書いた記憶があったが、

javaでノンブロッキングでも大丈夫か検証してみた。

javaのredisクライアントはlettuceを使用し、

1つのコネクションを、

マルチスレッドで共有し、SET、GETを試みたところ、

結果にずれは生じなかった。

結論として、

redisはシングルスレッドであるため、

持続的接続の場合は１コネクションでOK。

ただし、javaではマルチスレッドの性能を生かすため、

CPU数 x 2〜3 ぐらいがいいのかなとは思う。

ちなみに、上記でやっても問題なしでした。

以上

JavaMailでSMTP接続をして、

メールを送信しようとした時、

javax.mail.MessagingException: 501 Syntax: HELO hostname

のエラーがでることがある。

これは送信元のサーバのホスト名が

/etc/hostsに掲載されていない場合に起こる。

その他にも色々方法はあるようだが、

/etc/hostsにhostnameをしっかり書いておくことは大事です。

とはいえ、最近クラウドばかり使っていると、

この辺疎かになりがち。。

javaのweb socketで、decoderとpathparamはある条件において不可能なようなだ。

以下の場合はダメ。

@ServerEndpoint(
  value = "/ws/{p1}/{p2}/"
  decoders = {HogeDecoder.class},
  encoders = {HogeEncoder.class})
public class HogeWebsocket {
  /**
   * open hander.
   */
  @OnOpen
  public void onOpen(@PathParam("p1") String p1, Session session, EndpointConfig config) {
    :
    :  
  }
}

これだと、p1がdecoderの対象になるみたい。

そのため、次のような方法で対処する。

@ServerEndpoint(
  value = "/ws/{p1}/{p2}/"
  decoders = {HogeDecoder.class},
  encoders = {HogeEncoder.class})
public class HogeWebsocket {
  /**
   * open hander.
   */
  @OnOpen
  public void onOpen(Session session, EndpointConfig config) {
    Map<String, String> pathParameters = session.getPathParameters();
    String p1 = pathParameters.get("p1");
    :  
  }
}

本件は、decoderでバイナリからテキストに変換しようとした際に起きた現象。

なので、decoderが何をするかによるとは思うが。。

javaのページを見たが、それらしき記述はなかった。。

redisの冗長化を行うためには、

• master <-> slave構成
• master <-> slave構成 + sentinel
• cluster

がある。

clusterはredis3より正式サポートされた機能である。

特徴としては、以下の通り。

master <-> slave構成だと、

masterが倒れたときのフェイルオーバが皆無である。

master <-> slave構成 + sentinelだと、

masterが倒れたときに、slaveが自動昇格できる。

ただ、slave x 2以上、sentinel x 3以上が望ましい感じがする。

cluster構成だと、

分散でデータを保持しているため、

slaveも同時に使い、自動昇格させる必要がある。（slaveがあれば自動昇格する）

master x 3以上、slave x 3以上にする必要がある。

と考えると、clusterが一番な気がするが、

clusterの欠点は以下の通り。

1. selectはない
2. multi – execができない？
3. 対応しているクライアントライブラリが少ない
4. リダイレクトが発生するため、速度が遅くなる？
5. クラスター再構築が難しめ

などなど。

とくに、クライアントライブラリが少ないのは気がかりである。

python, rubyではあるらしい。

javaでもlettuceが対応している。

javaのコードは以下の通り。

List<RedisURI> list = new ArrayList<>();
list.add(new RedisURI("192.168.1.45", 16381, 1, TimeUnit.SECONDS));
list.add(new RedisURI("192.168.1.45", 16382, 1, TimeUnit.SECONDS));
list.add(new RedisURI("192.168.1.45", 16383, 1, TimeUnit.SECONDS));
list.add(new RedisURI("192.168.1.45", 16384, 1, TimeUnit.SECONDS));
list.add(new RedisURI("192.168.1.45", 16385, 1, TimeUnit.SECONDS));
list.add(new RedisURI("192.168.1.45", 16386, 1, TimeUnit.SECONDS));

RedisClusterClient client = RedisClusterClient.create(new Iterable<RedisURI>() {
  @Override
  public Iterator<RedisURI> iterator() {
    return list.iterator();
  }
});

AsyncExecutions<String> excutions = null;

RedisAdvancedClusterAsyncCommands<String, String> con = client.connect().async();

AsyncNodeSelection<String, String> masters = con.masters();

excutions = masters.commands().set("hoge", "fuga");

excutions.forEach(result -> result.thenAccept(ret -> System.out.println(ret)));
excutions = masters.commands().get("hoge");

excutions.forEach(result -> result.thenAccept(ret -> System.out.println(ret)));
con.close();
client.shutdown();

しかし、multi – execができないのは結構痛い。。。

うまいことやればできるのかな。。

ただ、分散してしまうから、無理なきがする。

このlettuceっていうライブラリは良さげ。

nettyをベースに使っていて、

ノンブロッキングをサポートしているしね。

当サイトはhttpサーバとして、

nginxで運用しているのだが、

nginxをipv4とipv6のハイブリット運用に変更したので、

メモを残す。

nginx.conf

user nginx;
worker_processes 1;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
events {
  worker_connections 1024;
  multi_accept on;
  use epoll;
}

http {
  server_tokens off;
  sendfile on;
  tcp_nopush on;
  tcp_nodelay on;

  keepalive_timeout 10;
  client_header_timeout 10;
  client_body_timeout 10;
  reset_timedout_connection on;

  send_timeout 10;
  include /etc/nginx/mime.types;
  default_type application/octet-stream;
  charset UTF-8;

  server {
    listen 80;
    listen [::]:80 ipv6only=on;
  }
  include /etc/nginx/conf.d/*.conf;
}

そして、一部sslサイトがあるので、

ssl側は以下のようにする。

※httpでアクセスしてきたときのリダイレクトも入れている

server {
  server_name  example.com;
  return 301 https://$host$request_uri;
}

server {
  listen 443;
  listen [::]:443 ipv6only=on ssl;

  ssl on;
  ssl_certificate /etc/pki/tls/certs/server.crt;
  ssl_certificate_key /etc/pki/tls/certs/server.key;

  server_name example.com;
  :
  :
}

netstatの結果、

nginxがipv4の80と443、ipv6の80と443で待ち受けていることがわかる。

# netstat -tnlp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      27124/nginx: master
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      27124/nginx: master
tcp6       0      0 :::443                  :::*                    LISTEN      27124/nginx: master
tcp6       0      0 :::80                   :::*                    LISTEN      27124/nginx: master

ちなみに、centos7で、nginxのバージョンは1.6.3です。