비동기식, 비차 단식, 이벤트 기반 아키텍처의 차이점은 무엇입니까?
차이점은 무엇입니까?
- 비동기 ,
- 비 차단 및
- 이벤트 기반 아키텍처?
뭔가가 될 수 모두 비동기 및 비 차단 (및 이벤트 기반 )?
프로그래밍에서 가장 중요한 것은 비동기, 비 차단 및 / 또는 이벤트 기반 (또는 3 개 모두)일까요?
예를 들어 보면 좋을 것입니다.
이 질문은 비슷한 주제에 대한 훌륭한 StackOverflow 기사를 읽었 기 때문에 제기 되었지만 위의 질문에 대한 답변이 아닙니다.
비동기 비동기는 말 그대로 동기가 아님을 의미합니다. 이메일은 비동기 적입니다. 메일을 보내면 지금 응답을받을 수 없습니다. 그러나 그것은 비 차단이 아닙니다. 본질적으로 이것이 의미하는 것은 "구성 요소"가 즉시 응답을 기대하지 않고 서로에게 메시지를 보내는 아키텍처입니다. HTTP 요청은 동기식입니다. 요청을 보내고 응답을받습니다.
Non-Blocking 이 용어는 주로 IO와 함께 사용됩니다. 이것이 의미하는 바는 시스템 호출을 할 때 스레드를 잠자기 상태로 두지 않고 (높은 확률로) 어떤 결과가 있든 즉시 반환한다는 것입니다. 예를 들어 비 차단 읽기 / 쓰기 호출은 할 수있는 모든 것을 반환하고 호출자가 호출을 다시 실행할 것으로 기대합니다. 예를 들어 try_lock은 비 차단 호출입니다. 잠금을 획득 할 수있는 경우에만 잠 깁니다. 시스템 호출에 대한 일반적인 의미는 차단입니다. 읽기는 데이터가있을 때까지 대기하고 호출 스레드를 절전 모드로 전환합니다.
이벤트 기반 이 용어는 libevent에서 유래되었습니다. 비 차단 읽기 / 쓰기 호출 자체는 "언제"다시 전화해야하는지 (재시도) 알려주지 않기 때문에 쓸모가 없습니다. select / epoll / IOCompletionPort 등은 이러한 호출이 "흥미로운"데이터를 반환 할 것으로 예상되는 "언제"OS에서 알아 내기위한 다른 메커니즘입니다. libevent 및 기타 이러한 라이브러리는 다양한 OS에서 제공하는 이러한 이벤트 모니터링 기능에 대한 래퍼를 제공하고 운영 체제에서 실행되는 일관된 API를 제공합니다. 비 차단 IO는 이벤트 기반과 함께 사용됩니다.
저는이 용어가 겹치는 것 같습니다. 예를 들어 HTTP 프로토콜은 동기식이지만 비 차단 IO를 사용하는 HTTP 구현은 비동기식 일 수 있습니다. 다시 읽기 / 쓰기 / try_lock과 같은 비 차단 API 호출은 동기식 (즉시 응답 제공)이지만 "데이터 처리"는 비동기식입니다.
비동기 하드웨어에서 코드는 어떤 엔티티에 무언가를 요청하고 액션이 완료되는 동안 다른 일을 자유롭게 할 수 있습니다. 작업이 완료되면 엔티티는 일반적으로 어떤 방식 으로든 코드에 신호를 보냅니다. 비 차단 아키텍처는 코드가 관심을 가질 수있는 자발적으로 발생하는 작업을 기록하고 코드가 그러한 작업이 발생했는지 묻도록 허용하지만 코드는 명시 적으로 해당 작업에 대해 물어볼 때만 이러한 작업을 인식합니다. 이벤트 기반 아키텍처는 이벤트가 자발적으로 발생하면 코드에 긍정적으로 알립니다.
코드가 1,000 바이트를 수신하려는 직렬 포트를 고려하십시오.
차단 읽기 아키텍처에서 코드는 1,000 바이트가 도착하거나 포기하기로 결정할 때까지 대기합니다.
비동기 읽기 아키텍처에서 코드는 드라이버에게 1,000 바이트가 필요하다는 것을 알리고 1,000 바이트가 도착하면 알림을받습니다.
비 차단 아키텍처에서 코드는 언제든 도착한 바이트 수를 물어볼 수 있으며, 적합하다고 판단되면 그러한 데이터의 일부 또는 전부를 읽을 수 있지만, 모든 데이터가 도착했을 때 알 수있는 유일한 방법은 묻는 것입니다. 코드가 1000 번째 바이트가 도착했을 때 1/4 초 이내에 알아 내려면 1/4 초 정도마다 확인해야합니다.
이벤트 기반 아키텍처에서 직렬 포트 드라이버는 데이터가 도착할 때마다 애플리케이션에 알립니다. 드라이버는 애플리케이션이 원하는 바이트 수를 알지 못하므로 애플리케이션은 애플리케이션이 원하는 것보다 작거나 큰 양에 대한 알림을 처리 할 수 있어야합니다.
나에게 non-blocking은 스레드에서 작업의 예외가 다른 스레드의 실행에 의존하지 않고 특히 중요 섹션이 필요하지 않음을 의미합니다.
비동기는 예외가 호출자의 흐름 외부에서 발생하고 잠재적으로 무시됨을 의미합니다. 실행은 일반적으로 다른 스레드에서 발생합니다.
동시 데이터 읽기는 비 차단 (잠글 필요 없음)이지만 동기식입니다. 역으로 동기식으로 동시에 데이터를 쓰는 것은 차단 (배타적 잠금 필요)입니다. 기본 흐름의 관점에서 비 차단으로 만드는 방법은 쓰기를 비동기로 만들고 실행을 연기하는 것입니다.
이벤트의 개념은 다른 것입니다. 대략적으로 말하면 무언가가 발생하면 알림을 받는다는 의미입니다. 쓰기가 비동기 적으로 실행 된 경우 쓰기가 실행 된 후 시스템의 다른 부분에 알리기 위해 이벤트가 발생할 수 있습니다. 다른 부분은 이벤트에 응답합니다. 시스템은 구성 요소간에 통신하는 유일한 방법 (액터 모델을 생각)으로 이벤트를 기반으로 만 구축 할 수 있지만 반드시 그럴 필요는 없습니다.
세 용어는 관련이 있지만 저에게는 다른 개념입니다. 그러나 사람들은 다소 상호 교환 가능한 방식으로 사용할 수 있습니다.
일반적으로 비 차단 아키텍처는 작업자 스레드에서 오랫동안 실행될 수 있지만 호출 스레드를 차단하지 않는 메서드 호출을 기반으로 합니다. 호출 스레드가 작업자 스레드가 실행중인 작업에 대한 정보를 획득해야하는 경우이를 수행하는 것은 호출 스레드에 달려 있습니다.
이벤트 기반 아키텍처는 실행되는 이벤트에 대한 응답으로 실행되는 코드의 개념을 기반으로합니다. 일반적으로 코드 실행 타이밍은 결정적이지 않지만 이벤트는 차단 메서드를 호출 할 수 있습니다. 시스템이 이벤트 기반이라고해서 모든 것이 차단되지 않는다는 의미는 아닙니다.
일반적으로 비동기 아키텍처는 이벤트 기반 비 차단 아키텍처입니다.
비동기 호출이 이루어지면 호출자가 관심있는 일이 발생했음을 호출자에게 알리기 위해 동기화 서비스를 제공하는 API에 이벤트 핸들러가 등록됩니다. 그러면 호출이 즉시 반환되고 (비 차단 동작) 호출자는 자유롭게 실행을 계속할 수 있습니다. 이벤트가 호출 프로세스로 다시 시작되면 해당 프로세스의 일부 스레드에서 처리됩니다.
이벤트가 동일한 스레드에서 처리되는지 여부를 이해하는 것이 중요합니다. 이는 실행의 비 차단 특성에 영향을 미치기 때문입니다. 그러나 저는 개인적으로 단일 스레드에서 비동기 실행 관리를 수행하는 라이브러리를 알지 못합니다.
위의 단락은 명시된대로 엄격하게 정확하지 않기 때문에 삭제했습니다. 내 의도는 OS 시설에 대한 호출 및 계속 실행과 같이 시스템 의 작업 이 비 차단 적 임에도 불구하고 단일 스레드 실행의 특성은 이벤트가 발생하면 이벤트가 스레드의 계산 시간에 대한 기타 처리 작업.
따라서 첫 번째와 두 번째 질문에 답하려면 :
비 차단은 사실상 비동기와 동일합니다. 호출을하면 나중에 결과를 얻을 수 있지만 그 동안 다른 작업을 수행 할 수 있습니다. 차단은 그 반대입니다. 여행을 계속하기 전에 전화가 돌아올 때까지 기다립니다.
Now Async/Non-blocking code sounds absolutely fantastic, and it is. But I have words of warning. Async/Non-blocking are great when working in constrained environments, such as in a mobile phone... consider limited CPU / memory. It's also good for front-end development, where your code needs to react to a UI widget in some way.
Async is fundamental to how all operating systems need to work - they get shit done for you in the background and wake your code up when they've done what you asked for, and when that call fails, you're told it didn't work either by an exception, or some kind of return code / error object.
At the point of when your code asks for something that will take a while to respond, your OS knows it can get busy with doing other stuff. Your code - a process, thread or equivalent, blocks. Your code is totally oblivious to what else is going on in the OS while it waits for that network connection to be made, or while it waits for that response from an HTTP request, or while it waits for that read/write a file, and so on. You code could "simply" be waiting for a mouse click. What actually was going on at during that time was your OS is seamlessly managing, scheduling and reacting to "events" - things the OS is looking out for, such as managing memory, I/O (keyboard, mouse. disk, internet), other tasks, failure recovery, etc.
Operating Systems are frickin' hard-core. They are really good at hiding all of the complicated async / non-blocking stuff from you the programmer. And that's how most programmers got to where we are today with software. Now we're hitting CPU limits, people are saying things can be done in parallel to improve performance. This means Async / non-blocking seems like a very favourable thing to do, and yes, if your software demands it, I can agree.
If you're writing a back-end web server, then proceed with caution. Remember you can scale horizontally for much cheaper. Netflix / Amazon / Google / Facebook are obvious exceptions to this rule though, purely because it works out cheaper for them to use less hardware.
I'll tell you why async / non-blocking code is a nightmare with back-end systems....
1) It becomes a denial of service on productivity... you have to think MUCH more, and you make a lot of mistakes along the way.
2) Stack traces in reactive code becomes undecipherable - it's hard to know what called what, when, why and how. Good luck with debugging.
3) You have to think more about how things fail, especially when many things come back out of order to how you sent them. In the old world, you did one thing at a time.
4) It's harder to test.
5) It's harder to maintain.
6) It's painful. Programming should be a joy and fun. Only masochists like pain. People who write concurrent/reactive frameworks are sadists.
And yes, I've written both sync and async. I prefer synchronous as 99.99 of back-end applications can get by with this paradigm. Front-end apps need reactive code, without question, and that's always been the way.
Yes, code can be asynchronous, non-blocking AND event-based.
The most important thing in programming is to make sure your code works and responds in an acceptable amount of time. Stick to that key principle and you can't go wrong.
'Programing' 카테고리의 다른 글
| 다른 동기화 된 메서드에서 동기화 된 메서드를 호출하는 것이 안전합니까? (0) | 2020.10.15 |
|---|---|
| Java Final 변수에 기본값이 있습니까? (0) | 2020.10.15 |
| Spring Java 구성에서 @Bean 주석이 달린 메소드 호출 (0) | 2020.10.15 |
| Visual Studio 15에서 "여기까지 실행"을 비활성화하는 방법은 무엇입니까? (0) | 2020.10.15 |
| matplotlib의 imshow를 사용하여 NaN 값을 특수 색상으로 어떻게 플롯 할 수 있습니까? (0) | 2020.10.15 |