그동안 consolas 를 가장 애용했었는데 아래 2개의 글꼴도 참 좋네요.

1. hack

다운로드 : https://sourcefoundry.org/hack/

위에서 다운로드 받아서 설치해도 되고, 파일 올려둡니다.

Hack-v2_013-ttf.zip

압축 해제한다음에 각각 글꼴 파일 더블클릭하면 설치되네요 (윈도우 8.x)

글 폭이  좀 많이 넓어지는 느낌. (개인적 취향에는 딱 맞습니다 ^^)

2. naver d2 

http://dev.naver.com/projects/d2coding

Half Close 란?

 half-closed connection 을 말하는데  TCP 특성상 양쪽에서 받고 보내는 연결이 2중이 되는데 , 한 쪽만 

닫는것을 말합니다. 종료시에 보통 입력 스트림을 살리고 전송 스트림은 닫습니다. 

When shutting down a TCP connection, something curious occurs. The TCP connection is duplex: data flows in both directions. And it's created in this manner -- it is impossible to create "half" a TCP connection, that would let data flow only from one end to the other. The SYN/ACK handshaking creates both directions at once or fails. Of course, your program might use the TCP connection to stream data in only one direction. But both directions are there...

When closing the connection, something else occurs. A party wishing to close its side of the TCP connection sends a FIN (i.e. a header with this bit set, along with any of the usual ACKs etc.). Like a SYN at the beginning of the connection, the FIN consumes a TCP sequence number, so it can be ACKed. And after the other party ACKs, the connection is half-closed! The party which sent the FIN can no longer send data -- but the other party may continue to send data.To close the TCP stream fully, both sides must send a FIN for "their" half of the connection. What possible use is a half-open connection?

In fact, a great deal of use. TCP streams share a great deal of intended functionality with UN*X pipes. In particular, it is often useful to think of sending a FIN in the same way as sending an EOF to the other side. Many processes can only compute their output after they finish reading their input. If you wish to connect such a program to a TCP stream, you'll need to denote the end of input in some manner -- and that manner is TCP's FIN.

For instance, suppose we have a program md5sum which computes the MD5 checksum of its input. md5sum reads its entire input, and only then generates output. Suppose further I have a file xyzzy on machinealice, and the program md5sum on machine bob. How can I compute the checksum?

alice% rsh bob md5sum < xyzzy

does the trick.

md5sum cannot produce any output until it knows its read all its input. Thus, no application data will flow from bob to alice until alice sends FIN. As soon as alice sends FIN, rsh on bob knows that its standard input has ended, and closes md5sum's input. Now md5sum can output its application data, which is transmitted on the half-open side of the TCP stream. Immediately following this data comes bob's FIN, closing the other half of the connection.

Without the TCP's half-close, some out of band data would have had to be used, significantly complicating TCP. A half-closed pipe is useful.

http://everything2.com/title/TCP+half-close

JAVA OIO

그림에 있는 순서대로 흘러가면 됩니다.

- 서버쪽에서는 Accept 를 통해 클라이언트의 접속을 기다리며 

- 접속이 되면 , 해당 클라이언트만을 위한 쓰레드를 생성합니다.

- 그 후 클라이언트는 그 쓰레드와 통신을 하게됩니다.

- 결국 클라이언트 만큼 쓰레드가 서버에 생성됩니다.

JAVA NIO

- 위 그림의 Java NIO 서버는 Hadoop 이라는 오픈소스 코어에서 가져왔습니다.

- 클라이언트측은 OIO (Old Input/Output) 이며, 서버는 NIO (New input /output) 입니다.

- 셀렉터, 채널 , 바이트버퍼의 개념을 알아야 이해할수있습니다.

- 보시다시피 굉장히 복잡하기때문에 , 스스로 만드는것 보다는 오래 검증된 라이브러리 (Netty) 같은것을
  사용하는편이 안전합니다.

- 클라이언트와 쓰레드 갯수와 무관해집니다. 

위의 그림은 오프라인 스터디용으로 작성하였기때문에, 여기에 구체적인 설명은 하지 않겠습니다.  ^^

P.S

TCP 는 연결지향이지만 메세지의 끝이 불분명하기때문에 양측에서 메세지의 처음과 끝을 약속하여 처리합니다.

- 문자열을 보낼때, 라인단위로 보냅니다. 그러면 수신측에서는 /n 을 발견할때까지 읽어서 처리합니다.

- /n 를 하나의 메세지의 끝으로 약속했을때, 메세지 안에 바이너리 데이터가 있다면 Base64 등으로 문자인코딩함.

- 처음 4바이트를 읽어서, 메세지의 길이를 확인한후에 길이만큼 바이트를 읽습니다.  ( 위에 하둡에서 이렇게 처리) 

- sync:cmd:datal-length:-------- data ------------:endSync  이런식으로 완전한 패킷정의 

스택오버플로우에 이희승씨가 요렇게 남겼네요.

- 3.x 은  deprecated 되었습니다. 유저들이 아직 많이들 사용하니깐 유지보수는 해드려요.

- 4.0 는 현재 안정화 버전입니다. 먼가 의심스러우면 요걸 쓰세요.

- 4.1 는 4.0 의 하위호환버전입니다.  몇가지 쩌는 것들을 추가했는데요. HTTP/2 나  asynchronous DNS resolver 같은거 말이죠.  그래서  4.1 은 이미 님의 어플이 4.0에서 돌아간다면 새버전으로 바꾸시는게 어떨까 하네요.

- 5.0 은 하위호환되지 않는 버전입니다.이건 4.0 처럼 rewrite 된건 아닌데요. 몇가지 디자인 결함을 바로 잡았습니다. Netty4 를 사용하고계시다면 Netty5 로 바꾸려면 몇가지 코드를 수정해야합니다.그건 Netty 3 을 Netty4 로 포팅하는것과는 다릅니다. 결국 4.x 도 deprecated  될것이고 5.0이 안정화 버전이 되겠지요.

4.0 의 주요 새로운점 

* Most buffers are dynamic with maximum capacity

// No more dynamicBuffer() - use buffer().
ByteBuf buf = Unpooled.buffer();

// Increase the capacity of the buffer.
buf.capacity(1024);
...

// Decrease the capacity of the buffer (the last 512 bytes are deleted.)
buf.capacity(512);

Channel channel = ...;
ByteBufAllocator alloc = channel.alloc();
ByteBuf buf = alloc.buffer(512);
....
channel.write(buf);

ChannelHandlerContext ctx = ...
ByteBuf buf2 = ctx.alloc().buffer(512);
....
channel.write(buf2)

http://netty.io/wiki/new-and-noteworthy-in-5.0.html 정리중 

1. 생산자 (Sender) 테스트 

   1. 결과 
      
   2. 이유
      1. 카프카 생산자는 브로커로 부터의 ack 를  기다리지 않고 메세지를 보낸다.브로커가 핸들링 할수있는 만큼 빠르게 메세지를 마구 보낸다.
      2. 카프카는 좀더 효율적인 저장소 포맷을 가지고있다. 평균적으로 카프카 각 메세지들은 9byte 의 오버헤드를 가지며, 반면 ActiveMQ 에서는 144 bytes 를 가진다. 이것은 메세지 헤더때문인데  JMS 에 의해 요구되어진것과 다양한 인덱싱구조를 유지하기위한 것이다. LinkedIn 은 관찰하길  ActiveMQ 의 가장 바쁜쓰레드는 메세지 메타데이터와 상태를 유지하기위한 B-Tree 에 접근하기위해 대부분의 시간을 소비하는것을 발견했다.
         
         

소비자 (Receiver) 테스트

1. 결과

   
Reason
1. 카프카는 좀더 효율적인 저장소 포맷을 가지고있다. 브로커로부터 컨슈머로 데이터 이동시 아주 적은 바이트만 소비된다.
2. ActiveMQ 와  RabbitMQ 의 브로커는  모든 메세지에 대한 전달 상태를 유지해야한다. LinkedIn 팀은 ActiveMQ 쓰레드들 중 하나를 관찰했는데  KahaDB 페이지를 디스크에 쓰는데 매우 바쁜걸 발견했다.  대조적으로 카프카 브로커상에서는 디스크 쓰기 행위가 없다. 결론적으로 파일에 쓰는 API 를 사용하는것에 의해 카프카는 데이터이동에 관한 오버헤드를 감소시킬수있던것이다.

레퍼런스)

http://mungeol-heo.blogspot.kr/2015/01/kafka-vs-rabbitmq-vs-activemq.html  
http://prismoskills.appspot.com/lessons/System_Design_and_Big_Data/Chapter_12_-_RabbitMQ_vs_Kafka.jsp
http://prismoskills.appspot.com/lessons/System_Design_and_Big_Data/Chapter_12_-_RabbitMQ_vs_Kafka.jsp
https://suniphrase.wordpress.com/2015/05/07/messaging-system-comparison-kafka-vs-rabbitmq-vs-activemq/

Friday, January 2, 2015

역주: 메세지큐에 대한 글을 적기 전에 왜 메세지큐냐? 를 먼저 생각해봐야한다.

Hello World!

Work Queues

Distributing tasks among workers (the competing consumers pattern) (워커에게 하나씩 균등히 나누어 준다)

Round-robin dispatching

Fair dispatch

* 메세지를 하나의 큐에 보내면 , 소비자들이 나누어갖는데, 시간배분을 해준다. (위처럼 라운드로빈이라면 홀수로 받는 워커에 일이 가중될수도있다. 홀수로 보내지는 일이 항상 많을경우) 

Publish/Subscribe

Sending messages to many consumers at once (모든 소비자에게 다 준다) 

Exchanges

 * Exchanges 를 통해 여러개의 큐에  보낸다.  

 * 워커큐와 다른점은 워커큐는 항상 하나의 메세지는 하나의 컨슈머만 받을수있다는것이고, 

   생산자/소비자 패턴에서는 하나의 메세지를 여러 워커가 받을수있다라는 점. 

Bindings

Putting it all together

Routing

Receiving messages selectively (원하는 것을 가져가게 한다)

Direct exchange

Multiple bindings

Putting it all together

Receiving messages based on a pattern (topics) (특정 패턴에 기반해 나누어 가진다) 

Topic exchange

RPC

Request/reply pattern

레퍼런스: https://www.rabbitmq.com/getstarted.html  

The_Netty_Project_3.1_User_Guide.doc

MongoDB vs. Couchbase  (2)

Couchbase 의 문서는 JSON 인 반면  MongoDB 문서는 BSON 이다. 표기법은 많은 32비트 , 64비트 Integer 타입, 날짜타입, 바이트배열등을 포함한다. 양쪽은 모두 위치분석 데이타/쿼리를 지원하는데 카우치베이스는 아직 실험중이며 곧 완성될것이다. 2.4 새 몽고디비 버전에서는 풀 텍스트 검색이 포함되었으며 카우치베이스는 유사한 기능이 있는데 elasticsearch 플러그인이 필요하다.

카우치베이스와 몽고디비는 둘다 복제를 통한 데이타 안전을 제공하며, 둘다 클러스터링을 한다. 또한 둘다  샤딩을 통한 병렬접근을 제공한다. 카우치베이스와 몽고디비는 해쉬샤딩은 제공하는데 몽고디비는 범위샤딩 과 "태그" 샤딩도 제공한다. 이것은 양날의 칼인데 , 데이타베이스 관리에 유연함을 주는 동시에 오용은 클러스터에 밸런스를 깨지게하는 결과를 초래한다.

맵리듀스는 양쪽에 주요툴인데, 다른 목적으로 사용된다. 몽고디비에서는 일반적인 데이타 프로세싱, 정보집단화, 분석등을 위해 사용하며, 카우치베이스는 단지 데이타베이스를 쿼리하기위한 인덱스 생성용도로 사용한다. 그 결과 몽고디비가 인덱스 생성이나 애드혹 쿼리시엔느 좀 더 쉽긴하다.

카우치베이스는 메모리에 캐쉬하는것 (memcached) 이 장착되있는데,  몽고디비에는 대응되는것은 없다. Memcache 는  높은 처리량/데이타 집중 인터넷/ 인프라넷 어플리케이션 을 위해 오프젝트를 캐슁하는 시스템으로 강력하다. 만약 어플리케이션에서 Memcache 기능이 필요하다면 더 볼것도 없이 Couchbase 이다. 

두 시스템은  여러 유명 언어로 드라이버와 클라이언트 프레임워크를 제공하며 , 오픈소스이며 쉽게 인스톨할수있고 쉽게 온라인에서 문서를 찾을수있다. 

Couchbase Server vs MongoDB